Well, think of the entire session mechanism implementation. It can be simplified into a simple map, such as Hashtable, that holds references to other map objects indexed by some unique id. When a servlet calls request.getSession() for the first time, a new entry is inserted into the first, major, map. The key is generated on the fly by some uniqueness algorithm, and the value is, as mentioned, an empty map object. This second map is then returned to the calling servlet, which can now store other objects in it on a per-client basis. The second time the servlet calls request.getSession(), this mechanism detects the presence of a session id inside the client request, either in the form of a cookie, or as a URL parameter. it uses this session-id to pull the map stored inside the main repository and return it to the calling servlet, which can now access the same client session. The first map is actually the container for all present client session in the server, and the second-level maps are the containers of client-context information. The first can be stored in the ServletContext, for example, where it is visible to all servlets in the same web application, and that's just about it. You'd need to add session-timeout mechanism and maybe do some optimizations, but that's roughly it. zm.
-----Original Message----- From: A mailing list about Java Server Pages specification and reference [mailto:[EMAIL PROTECTED]]On Behalf Of Philip M. Meier Sent: Tuesday, January 01, 2002 7:47 PM To: [EMAIL PROTECTED] Subject: Re: Sessions and URL-Rewriting? First of all thank you, Zvika! I use JBoss 2.4 with Tomcat 4.01 and I didn't find any element in the DTD of the Deployment-Descriptor, which is able to force URLRewriting! So I will use the default properties, which is to use only URLRewriting, when cookies are not supported or allowed. Unfortunately I don't exactly understand your remarks to self made this! Thanks Philip > To the best of my knowledge, there is no mechanism defined in the spec that > allows you to force using URLRewriting rather than cookies. Some vendors > (BEA's Weblogic5.1, for instance) may let you do that, some won't. > However, you can implement such a mechanism yourself: > Use a Map stored in the ServletContext object that holds keys of session > id's (that you will generate yourself) and values that are name-value > containers (maps, again). supply some utility methods for embedding the > session_id parameter in a cookie or a url, and you've got yourself exactly > what needed. > > zm. =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
