♠ Posted by
Java Tutorials
at
11:30 PM
26.
What is difference between ServletResponse sendRedirect() and
RequestDispatcher forward() method?
RequestDispatcher
forward() is used to forward the same request to another resource whereas
ServletResponse sendRedirect() is a two step process. In sendRedirect(), web
application returns the response to client with status code 302 (redirect) with
URL to send the request. The request sent is a completely new request.
1.
forward() is
handled internally by the container whereas sednRedirect() is handled by
browser.
2.
We should use
forward() when accessing resources in the same application because it’s faster
than sendRedirect() method that required an extra network call.
3.
In forward()
browser is unaware of the actual processing resource and the URL in address bar
remains same whereas in sendRedirect() URL in address bar change to the
forwarded resource.
4.
forward()
can’t be used to invoke a servlet in another context, we can only use
sendRedirect() in this case.
HttpServlet class provide HTTP protocol
implementation of servlet but it’s left abstract because there is no
implementation logic in service methods such as doGet() and doPost() and we
should override at least one of the service methods. That’s why there is no
point in having an instance of HttpServlet and is declared abstract class.
We know that Servlet Container manages the life
cycle of Servlet, there are four phases of servlet life cycle.
1.
Servlet Class
Loading – When container receives request for a servlet, it first loads the
class into memory and calls it’s default no-args constructor.
2. Servlet Class Initialization – Once the servlet class is loaded, container initializes the ServletContext object for the servlet and then invoke it’s init method by passing servlet config object. This is the place where a servlet class transforms from normal class to servlet.
3. Request Handling – Once servlet is initialized, its ready to handle the client requests. For every client request, servlet container spawns a new thread and invokes the service() method by passing the request and response object reference.
4. Removal from Service – When container stops or we stop the application, servlet container destroys the servlet class by invoking it’s destroy() method.
2. Servlet Class Initialization – Once the servlet class is loaded, container initializes the ServletContext object for the servlet and then invoke it’s init method by passing servlet config object. This is the place where a servlet class transforms from normal class to servlet.
3. Request Handling – Once servlet is initialized, its ready to handle the client requests. For every client request, servlet container spawns a new thread and invokes the service() method by passing the request and response object reference.
4. Removal from Service – When container stops or we stop the application, servlet container destroys the servlet class by invoking it’s destroy() method.
Servlet Life Cycle consists of three methods:
1.
public void
init(ServletConfig config) – This method is used by container to initialize the
servlet, this method is invoked only once in the lifecycle of servlet.
2.
public void
service(ServletRequest request, ServletResponse response) – This method is
called once for every request, container can’t invoke service() method until
unless init() method is executed.
3.
public void
destroy() – This method is invoked once when servlet is unloaded from memory.
If we have to initialize some resource before we
want our servlet to process client requests, we should override init() method.
If we override init(ServletConfig config) method, then the first statement
should be super(config) to make sure superclass init(ServletConfig config)
method is invoked first. That’s why GenericServlet provides another helper
init() method without argument that get’s called at the end of
init(ServletConfig config) method. We should always utilize this method for
overriding init() method to avoid any issues as we may forget to add super()
call in overriding init method with ServletConfig argument.
URL Encoding is the process of converting data into
CGI form so that it can travel across the network without any issues. URL
Encoding strip the white spaces and replace special characters with escape
characters. We can use java.net.URLEncoder.encode(String str, String unicode)
to encode a String. URL Decoding is the reverse process of encoding and we can
use java.net.URLDecoder.decode(String str, String unicode) to decode the
encoded string. For example “Pankaj’s Data” is encoded to “Pankaj%27s+Data”.
Session is a conversional state between client and
server and it can consists of multiple request and response between client and
server. Since HTTP and Web Server both are stateless, the only way to maintain
a session is when some unique information about the session (session id) is
passed between server and client in every request and response.
Some of the common ways of session management in
servlets are:
1.
User
Authentication
2.
HTML Hidden
Field
3.
Cookies
4.
URL Rewriting
5.
Session
Management API
We can use HttpSession for session management in
servlets but it works with Cookies and we can disable the cookie in client
browser. Servlet API provides support for URL rewriting that we can use to
manage session in this case.
The best part is that from coding point of view,
it’s very easy to use and involves one step – encoding the URL. Another good
thing with Servlet URL Encoding is that it’s a fallback approach and it kicks
in only if browser cookies are disabled.
We can encode URL with HttpServletResponse
encodeURL() method and if we have to redirect the request to another resource
and we want to provide session information, we can use encodeRedirectURL()
method.
Cookies are used a lot in web client-server
communication, it’s not something specific to java. Cookies are text data sent
by server to the client and it gets saved at the client local machine.
Servlet API provides cookies support through
javax.servlet.http.Cookie class that implements Serializable and Cloneable
interfaces.
HttpServletRequest getCookies() method is provided
to get the array of Cookies from request, since there is no point of adding
Cookie to request, there are no methods to set or add cookie to request.
Similarly HttpServletResponse addCookie(Cookie c)
method is provided to attach cookie in response header, there are no getter
methods for cookie.
If we have to
make sure an object gets notified when session is destroyed, the object should
implementjavax.servlet.http.HttpSessionBindingListener interface. This interface
defines two callback methods – valueBound() and valueUnbound() that we can
define to implement processing logic when the object is added as attribute to
the session and when session is destroyed.
HttpServletResponse provide method to encode URL in
HTML hyperlinks so that the special characters and white spaces are escaped and
append session id to the URL. It behaves similar to URLEncoder encode method
with additional process to append jsessionid parameter at the end of the URL.
However HttpServletResponse encodeRedirectUrl()
method is used specially for encode the redirect URL in response.
So when we are providing URL rewriting support, for
hyperlinks in HTML response, we should use encodeURL() method whereas for
redirect URL we should use encodeRedirectUrl() method.
Servlet Filters are pluggable java components that
we can use to intercept and process requests before they are sent to servlets
and response after servlet code is finished and before container sends the
response back to the client.
Some common tasks that we can do with filters are:
§ Logging request parameters
to log files.
§ Authentication and
autherization of request for resources.
§ Formatting of request body
or header before sending it to servlet.
§ Compressing the response
data sent to the client.
§ Alter response by adding
some cookies, header information etc.
38.
What is the effective way to make sure all the servlets are accessible
only when user has a valid session?
We know that servlet filters can be used to
intercept request between servlet container and servlet, we can utilize it to
create authentication filter and check if request contains a valid session or
not.
We know that using ServletContext, we can create an
attribute with application scope that all other servlets can access but we can
initialize ServletContext init parameters as String only in deployment
descriptor (web.xml). What if our application is database oriented and we want
to set an attribute in ServletContext for Database Connection.
If you application has a single entry point (user
login), then you can do it in the first servlet request but if we have multiple
entry points then doing it everywhere will result in a lot of code redundancy.
Also if database is down or not configured properly, we won’t know until first
client request comes to server. To handle these scenario, servlet API provides
Listener interfaces that we can implement and configure to listen to an event
and do certain operations.
40.
How to handle exceptions thrown by application with another servlet?
If you notice, doGet() and doPost() methods throw
ServletException and IOException. Since browser understand only HTML, when our
application throw exception, servlet container processes the exception and
generate a HTML response. Same goes with other error codes like 404, 403 etc.
Servlet API provides support for custom Exception
and Error Handler servlets that we can configure in deployment descriptor, the
whole purpose of these servlets are to handle the Exception or Error raised by
application and send HTML response that is useful for the user. We can provide
link to application home page or some details to let user know what went wrong.
We can configure them in web.xml like below:
1
|
<error-page>
|
|
2
|
<error-code>404</error-code>
|
|
3
|
<location>/AppExceptionHandler</location>
|
|
4
|
</error-page>
|
|
5
|
||
6
|
<error-page>
|
|
7
|
<exception-type>javax.servlet.ServletException</exception-type>
|
|
8
|
<location>/AppExceptionHandler</location>
|
|
9
|
</error-page>
|
Deployment descriptor is a configuration file for
the web application and it’s name is web.xml and it resides in WEB-INF
directory. Servlet container use this file to configure web application
servlets, servlet config params, context init params, filters, listeners,
welcome pages and error handlers.
With servlet 3.0 annotations, we can remove a lot
of clutter from web.xml by configuring servlets, filters and listeners using
annotations.
Usually servlet container loads a servlet on the
first client request but sometimes when the servlet is heavy and takes time to
loads, we might want to load it on application startup. We can use
load-on-startup element with servlet configuration in web.xml file or use
WebServlet annotation loadOnStartup variable to tell container to load the
servlet on system startup.
1
|
<servlet>
|
|
2
|
<servlet-name>foo</servlet-name>
|
|
3
|
<servlet-class>com.foo.servlets.Foo</servlet-class>
|
|
4
|
<load-on-startup>5</load-on-startup>
|
|
5
|
</servlet>
|
The load-on-startup value should be int, if it’s 0
or negative integer then servlet container will load the servlet based on
client requests and requirement but if it’s positive, then container will load
it on application startup.
If there are multiple servlets with load-on-startup
value as 1,2,3 then lower integer value servlet will be loaded first.
We can use following code snippet to get the actual
path of the servlet in file system.
1
|
getServletContext().getRealPath(request.getServletPath())
|
We can use below code snippet to get the servlet
information in a servlet through servlet context object.
1
|
getServletContext().getServerInfo()
|
File Upload and Download and common tasks in a java
web application. Unfortunately Servlet API doesn’t provide easy methods to
upload file on server, so we can use Apache FileUpload jar to make our life
easier.
If you work with database connection a lot in your
web application, its best to initialize it in a servlet context listener and
set it as a context attribute for other servlets to use.
Integrating Log4j is also very easy in web
applications, all we need is a log4j configuration XML or property file and
then configure it in a servlet context listener.
We can use request.getRemoteAddr() to get the client IP
address in servlet.
Servlet Specs 3.0 was a major release and some of
the important features are:
1.
Servlet Annotations: Prior to Servlet 3, all
the servlet mapping and it’s init parameters were used to defined in web.xml,
this was not convenient and more error prone when number of servlets are huge
in an application.
Servlet 3 introduced use of java annotations to define a servlet, filter and listener servlets and init parameters. Some of the important Servlet API annotations are WebServlet, WebInitParam, WebFilter and WebListener. Read more about them atServlet 3 annotations.
Servlet 3 introduced use of java annotations to define a servlet, filter and listener servlets and init parameters. Some of the important Servlet API annotations are WebServlet, WebInitParam, WebFilter and WebListener. Read more about them atServlet 3 annotations.
2.
Web Fragments: Prior to servlet specs 3.0, all the web
application configurations are required to be present in the web.xml that makes
it cluttered with lot of elements and chances of error increases. So servlet 3
specs introduced web fragments where we can have multiple modules in a single
web application, all these modules should have web-fragment.xml file in
META-INF directory. We can include all the elements of web.xml inside the
web-fragment.xml too. This helps us in dividing our web application into
separate modules that are included as JAR file in the web application lib
directory.
3.
Adding Web Components dynamically: We can use ServletContext
object to add servlets, filters and listeners programmatically. This helps us
in building dynamic system where we are loading a component only if we need it.
These methods are addServlet(), addFilter() and addListener() defined in the
servlet context object.
49.
Asynchronous Processing: Asynchronous support was
added to delegate the request processing to another thread rather than keeping
the servlet thread busy. It can increase the throughput performance of the
application.
Servlet Container provides different ways of login
based servlet authentication:
1.
HTTP Basic Authentication
2.
HTTP Digest Authentication
3.
HTTPS Authentication
4.
Form Based Login: A standard HTML form for authentication,
advantage is that we can change the login page layout as our application
requirements rather than using HTTP built-in login mechanisms.
We can configure our servlet container to use SSL
for message communication over the network. To configure SSL on Tomcat, we need
a digital certificate that can be created using Java keytool for development
environment. For production environment, you should get the digital certificate
from SSL certificate providers, for example, Verisign or Entrust.
0 comments :
Post a Comment