Beruflich Dokumente
Kultur Dokumente
What are the differences between the ServletConfig interface and the ServletContext
interface?
ServletConfig ServletContext
The param-value pairs for ServletConfig object The param-value pairs for ServletContext
are specified in the <init-param> within the object are specified in the <context-param>
<servlet> tags in the web.xml file tags in the web.xml file.
forward() sendRedirect()
The browser is completely unaware that it has The browser, in this case, is doing the work
taken place, so its original URL remains intact. and knows that it's making a new request.
Any browser reload of the resulting page will A browser reloads of the second URL ,will not
simple repeat the original request, with the repeat the original request, but will rather fetch
original URL the second URL.
include() forward()
ServletRequest.getRequestDispatcher(Strin ServletContext.getRequestDispatcher(Strin
g path) g path)
A container does not initialize the servlets as soon as it starts up, it initializes a servlet when it
receives a request for that servlet first time. This is called lazy loading. The servlet specification
defines the element, which can be specified in the deployment descriptor to make the servlet
container load and initialize the servlet as soon as it starts up. The process of loading a servlet
before any request comes in is called preloading or preinitializing a servlet.
The <load-on-startup> element of a deployment descriptor is used to load a servlet file when
the server starts instead of waiting for the first request. It is also used to specify the order in
which the files are to be loaded.
. 30.What is session?
A session refers to all the requests that a single client might make to a server in the course of
viewing any pages associated with a given application. Sessions are specific to both the
individual user and the application. As a result, every user of an application has a separate
session and has access to a separate set of session variables.
31.What is Session Tracking?
Session tracking is a mechanism that servlets use to maintain state about a series of requests from
the same user (that is, requests originating from the same browser) across some period of time.
HTTP is a stateless protocol i.e., every request is treated as new request. For web applications to
be more realistic they have to retain information across multiple requests. Such information
which is part of the application is reffered as "state". To keep track of this state we need session
tracking.
Sessions need to work with all web browsers and take into account the users security
preferences. Therefore there are a variety of ways to send and receive the identifier:
URL rewriting : URL rewriting is a method of session tracking in which some extra data
(session ID) is appended at the end of each URL. This extra data identifies the session.
The server can associate this session identifier with the data it has stored about that
session. This method is used with browsers that do not support cookies or where the user
has disabled the cookies.
Hidden Form Fields : Similar to URL rewriting. The server embeds new hidden fields
in every dynamically generated form page for the client. When the client submits the
form to the server the hidden fields identify the client.
Secure Socket Layer (SSL) Sessions : Web browsers that support Secure Socket Layer
communication can use SSL's support via HTTPS for generating a unique session key as
part of the encrypted conversation.
34.How do I use cookies to store session state on the client?
To set a cookie on the client, use the addCookie() method in class HttpServletResponse.
Multiple cookies may be set for the same request, and a single cookie name may have
multiple values.
To get all of the cookies associated with a single HTTP request, use the getCookies()
method of class HttpServletRequest
Cookies are usually persistent, so for low-security sites, user data that needs to be stored
long-term (such as a user ID, historical information, etc.) can be maintained easily with
no server interaction.
For small- and medium-sized session data, the entire session data (instead of just the
session ID) can be kept in the cookie.
Advantages
URL rewriting works just about everywhere, especially when cookies are turned off.
Multiple simultaneous sessions are possible for a single user. Session information is local
to each browser instance, since it's stored in URLs in each page being displayed. This
scheme isn't foolproof, though, since users can start a new browser instance using a URL
for an active session, and confuse the server by interacting with the same session through
two instances.
Entirely static pages cannot be used with URL rewriting, since every link must be
dynamically written with the session state. It is possible to combine static and dynamic
content, using (for example) templating or server-side includes. This limitation is also a
barrier to integrating legacy web pages with newer, servlet-based pages.
DisAdvantages
Every URL on a page which needs the session information must be rewritten each time a
page is served. Not only is this expensive computationally, but it can greatly increase
communication overhead.
URL rewriting limits the client's interaction with the server to HTTP GETs, which can
result in awkward restrictions on the page.
URL rewriting does not work well with JSP technology.
If a client workstation crashes, all of the URLs (and therefore all of the data for that
session) are lost.
Setting timeout in the deployment descriptor: This can be done by specifying timeout
between the <session-timeout>tags as follows:
<session-config>
<session-timeout>10</session-timeout>
</session-config>
This will set the time for session timeout to be ten minutes.
Setting timeout programmatically: This will set the timeout for a specific session. The
syntax for setting the timeout programmatically is as follows:
40.A client sends requests to two different web components. Both of the components access the
session. Will they end up using the same session object or different session ?
Creates only one session i.e., they end up with using same session .
Sessions is specific to the client but not the web components. And there is a 1-1 mapping
between client and a session.
A container doesnot initialize the servlets ass soon as it starts up, it initializes a servlet
when it receives a request for that servlet first time. This is called lazy loading.
The servlet specification defines the <load-on-startup> element, which can be specified
in the deployment descriptor to make the servlet container load and initialize the servlet
as soon as it starts up.
The process of loading a servlet before any request comes in is called preloading or
preinitializing a servlet.
Servlet Chaining is a method where the output of one servlet is piped into a second servlet. The
output of the second servlet could be piped into a third servlet, and so on. The last servlet in the
chain returns the output to the Web browser.
43.How are filters?
Filters are Java components that are used to intercept an incoming request to a Web resource and
a response sent back from the resource. It is used to abstract any useful information contained in
the request or response. Some of the important functions performed by filters are as follows:
Security checks
Modifying the request or response
Data compression
Logging and auditing
Response compression
Filters are configured in the deployment descriptor of a Web application. Hence, a user is not
required to recompile anything to change the input or output of the Web application.
It intercepts the request from a client before it reaches the servlet and modifies the
request if required.
It intercepts the response from the servlet back to the client and modifies the request if
required.
There can be many filters forming a chain, in which case the output of one filter becomes
an input to the next filter. Hence, various modifications can be performed on a single
request and response
Lifecycle management : It manages the life and death of a servlet, such as class loading,
instantiation, initialization, service, and making servlet instances eligible for garbage
collection.
Communication support : It handles the communication between the servlet and the
Web server.
Multithreading support : It automatically creates a new thread for every servlet request
received. When the Servlet service() method completes, the thread dies.
Declarative security : It manages the security inside the XML deployment descriptor
file.
JSP support : The container is responsible for converting JSPs to servlets and for
maintaining them.