Background info... I am creating a web application that manages tasks for a user. Each task provides a link for the user to resolve the task. Each link will potentially take the user to another web application in another application server. The resolution applications will be opened in another browser window. This is so that the user can view their tasks, monitoring for new ones, at the same time that they are resolving a particular task. Both the task manager and the resolution applications will be using the HttpSession. Each will have its own HttpSession since they will each be in their own JVM. Question... Since I will have one browser instance with multiple windows, there will be only one JSESSIONID cookie on the client. I am in the design phase so I have not actually tried this, but I am assuming that it will not work to switch between windows because the cookie that is passed to the server will be for the JVM of the previous response. The end result is that I will lose the sessions. The only solution that I can think of would be to create a unique sessionId cookie name for each app server so that name collision does not occur. However, I understand that the Servlet Spec says that the cookie MUST be named JSESSIONID. Am I correct in my assessment that there is a problem? And if so, does anyone know of a solution? Also, why does the Servlet Spec require the cookie to be name JSESSIONID? Thanks in advance! Erick
Let me get this straight - these tasks that are running - are they web applications or not? Are they all running on the same server? If all the tasks are in the same web application they should see the same session. If not you will have to come up with another mechanism to share data. If you want the servlet container to manage a session for you, then you have to let it handle the JSESSIONID cookie. If you want to create your own session-like mechanism, you can create your own cookies. Bill
Bill, let me try to clarify... The Task Manager application runs in one Application Server. Each appplication that is launched from it will be a web application in another Application Server (another JVM). The issue is not that I need to share information between the two applications. This is not a requirement, and I know that this is not supported within the J2EE spec. The issue is that when the user launches a task resolution screen (which is in another app server) in another window, a new session will be created and a new JSESSIONID cookie will be sent back to the client. If the user now goes back to the Task Manager window, and initiates a request (via a POST), the cookie will have the sessionid of the HttpSession in the other JVM. Therefore, the web app will not be able to locate the session and it will be lost. Hope this helps better explain my situation. Any help is GREATLY appreciated. Erick
Erik, 1. Why not implement your soliution will URL rewriting? This would A) Solve the problem with multiple apps and B) allow for users who have cookies turned off. 2. Or if you want to stay with cookies you are able to choose between the various cookies via the set/getPath method of the C00kie Class and it's corresponing HTTP properties. Check out RFC 2109 at http://www.faqs.org/rfcs/rfc2109.html Below I posted the method.
javax.servlet.http.C00kie public void setPath(java.lang.String uri) Specifies a path for the cookie to which the client should return the cookie. The cookie is visible to all the pages in the directory you specify, and all the pages in that directory's subdirectories. A cookie's path must include the servlet that set the cookie, for example, /catalog, which makes the cookie visible to all directories on the server under /catalog. Consult RFC 2109 (available on the Internet) for more information on setting path names for cookies. Parameters: uri - a String specifying a path
[ December 07, 2002: Message edited by: Thomas Hubschman ]
Thomas, Thanks for the reply. The web applications that I am calling the 'Task Resolution applications' exist in our production environment today. So the impact of changing over to use URL re-writing would be very large. I hadn't thought of this being a solution to the problem, but I think it would work. The second point you made will work for me if I understand correctly. After reading RFC 2109, let me see if I understand correctly how the path of a cookie works: If two cookies have the same name and the same path, only one cookie will exist on the client. If two cookies have the same name, but different paths, two cookies will exist on the client. The cookie sent to the server is then based on the URI of the request. If this summary is correct, then I am a very happy man! Thanks again for your help! Erick
Joined: Sep 25, 2002
Erik, That is more or less my interpretation as well. Of course the only way to know for sure is to test it. I have not had to deal with this issue, so I would be curious to hear if it works!
Joined: Jun 17, 2002
Thomas, The results of my test confirmed our interpretation. Two cookies with the same name, but different paths, are both stored by the client and do not collide with each other. The correct cookie is then sent back to the server based on the URI path of the request. This is the solution to my problem. Thanks again for your help! Erick