Issuu on Google+




A conversation consists series of continuous request and response from a same client to a server, the server cannot identify from which client it is getting requests. Because HTTP is a stateless protocol. A conversational state is associated with "what the user is doing now, in this window". The conversation context allows us to ensure that state from the different conversations does not collide and cause bugs. Conversational State use case: When clients at an on- line store add an item to their shopping cart, how does the server know what’s already in the cart? When clients decide to proceed to checkout, how can the server determine which previously created shopping cart is theirs?


Example on Hidden Fields refer: 1) 2)



Cookies are generally a better solution than HTTP user authentication using hidden form fields and rewritten URLs because they're more object oriented for session management.

For more information on cookie refer :


1) Client makes a request, request object contains user data (email and password). 2) Web Container invokes service() [ can be GET or POST ]. 3) Servlet/JSP creates a cookie 4) Servlet adds the cookie to response 5) Servlet sends response to the client. Response now contains cookie information along with other details.

6) Cookie sent as response be server will be stored by the web browser.


The Page has three hyperlinks “Inbox”, “Compose” and “Logout”. For every action taken by the user: 1) Request is made from the same browser, along with actual request data cookie data will also be sent to the server. 2) Web container invokes the appropriate service() method of the servlet /jsp 3) The arguments to service() method are HttpServletRequest and HttpServletResponse. 4) The Request object contains cookie information which can be read by servlet/jsp to identify the conversational state of the client. Note: Every time now client need to enter his credentials. Server is identifying the user based on the information stored in cookie.


Only one cookie instance can be added at a time using addCookie(). Because cookies are sent using HTTP headers, they should be added to the response before you send any content. Browsers are only required to accept 20 cookies per site, 300 total per user, and they can limit each cookie's size to 4096 bytes. Some other important methods of Cookie class: public void Cookie.setMaxAge(int expiry) : Specifies the maximum age of the cookie in seconds before it expires. A negative value indicates the default, that the cookie should expire when the browser exits. A zero value tells the browser to delete the cookie immediately. public void Cookie.setDomain(String pattern): Specifies a domain restriction pattern. A domain pattern specifies the servers that should see a cookie. By default, cookies are returned only to the host that saved them. Specifying a domain name pattern overrides this. The pattern must begin with a dot and must contain at least two dots. A pattern matches only one entry beyond the initial dot. For example, "" is valid and matches and “” but not “”




The Servlet Session-Tracking API : The Java servlet session-tracking API provides a transparent way for the server-side developer to easily manage session data. It depends on URL rewriting or cookies. Generally, the basic idea of this API is that it provides a layer of indirection in session management. Instead of worrying about exactly how session data is managed (by cookies, by URL rewriting, etc.) the server-side engineer simply uses an API that can query or store named attributes. Like cookies, each attribute is essentially a name/value pair: The name is the name of the attribute; the value is associated with the attribute's value.


Refer: for information about other methods of HttpSession boolean isNew() Returns true if the client does not yet know about the session or if the client chooses not to join the session. String getId()

Returns a string containing the unique identifier assigned to this session. Enumeration getAttributeNames() Returns an Enumeration of String objects containing the names of all the objects bound to this session long getCreationTime() Returns the time when this session was created. long getLastAccessedTime() Returns the last time the client sent a request associated with this session. ServletContext getServletContext() Returns the ServletContext to which this session belongs.


HttpSession Objects stores data in the form of key/value pair. Unlike Cookies there is no limitation to the data stored in HttpSession API. Ideally you should use HttpSession to store only important information like username, email and bank account number, which needs to be used until session is alive. Do not use HttpSession object to store information like entire employee records, complete transaction details of your Bank account. These type of information should be ideally stored in request object.


Unlike cookies, in HttpSession API, the session information is stored within the server. Only Session ID is sent to the client (Web Browser) and not the complete client data. Subsequent requests only Session ID will be sent along with the request in the form of Cookie, using Session ID sent through Cookie, server identifies which session object belongs to that particular client.

Note: If Cookies are disabled, URL Rewriting can be used to send Session ID to/from Web browser. (Refer encodeURL() and encodeRedirectURL() methods of HttpServletResponse).



ServletConfig objects are created one per web component ( Servlet and JSP). ServletContext is created one per web application and shared by all the Servlet's and JSP pages. JSP page can access ServletContext using implicit “application” object.


For other methods refer : Some other important methods: java.util.Enumeration<java.lang.String> getAttributeNames() Returns an Enumeration containing the attribute names available within this ServletContext void log(java.lang.String message, java.lang.Throwable throwable) Writes an explanatory message and a stack trace for a given Throwable exception to the servlet log file. RequestDispatcher getNamedDispatcher(java.lang.String name) Returns a RequestDispatcher object that acts as a wrapper for the named servlet. RequestDispatcher getRequestDispatcher(java.lang.String path) Returns a RequestDispatcher object that acts as a wrapper for the resource located at the given path


The Context Parameters are configured in web.xml using <context-param> tag. This tag is a child element to <web-app> element. Each <context-param> tag contains <param-name> for defining the name of the parameter and <param-value> for defining the value for the parameters.

Unlike <init-param> which is accessable only by the component for which it is configured, the Context parameters can be read by any web component[ servlets and jsp ] of that web application.



Username should be available for all pages the user visits until the user Sign out, hence it should be stored as session attributes() Once the use makes a request the retrieved search data has to be displayed to the user, once the response is written the search results is no longer required hence it should be stored as request attributes. Promoted Videos are viewed by all the users of this web application. Promoted videos are not specify to the user and hence it is a right candidate for storing it in ServletContext. There are many better ways of implementing this but ServletContext is also an option.



Answers: 1) application.getAttribute(“data”) 2) YES: use Page directive and session attribute <%@ page session=“false” %> 3) NO : Once ServletConfig object is created by the container it is immutable. 4) FALSE: session is implict variable. Cookie is not an implicit variable you need to explicit create it in JSP page.


Answer: 5) TRUE. Cookies are stored in client machine. JavaScript can access all the cookies stored in the browser using document.cookies. 6) 1) TRUE 2) FALSE 3) FALSE 4) TRUE [ for explanation see notes section of slide 15] 7) HttpSession API can work even if Cookies are disabled by using URL Rewriting [ refer video JEE_video8b.swf ]







Servlet and Jsp Technology -Part3