-----Original Message-----
From: Williams, Nick [mailto:nicholas.willi...@ul.com]
Sent: Monday, February 11, 2013 5:24 PM
To: Tomcat Developers List (dev@tomcat.apache.org)
Subject: When to notify of changed session IDs?

>After discussing with Mark T, I'm working on implementing 
>HttpServletRequest.changeSessionId() and the calling of HttpSessionIdListeners 
>as introduced in the Servlet 3.1 specification. I'd like to help and it seemed 
>like a trivial enough item for me to tackle (I may regret saying that :-P).
>
>Tomcat already has some utilities built-in for changing session IDs, so that 
>helped me significantly. Currently I'm seeing that there are a couple places 
>where session IDs can already change in Tomcat:
>
>- Request is authenticated via some container-provided mechanism and 
>changeSessionIdOnAuthentication is enabled
>- A session ID is changed on one node in a cluster and it notifies the other 
>nodes to do the same
>
>When any of these happen, Context.fireContainerEvent() is called with 
>Context.CHANGE_SESSION_ID_EVENT.
>
>The Servlet 3.1 spec document doesn't deal with the new HttpSessionIdListener 
>directly, but the javadoc for Servlet 3.1 says that all HttpSessionIdListeners 
>will be of session ID changes. It doesn't say when 
>HttpServletRequest.changeSessionId() is called, it says "about HttpSession ID 
>changes". So, from where I standing, this means to me:
>
>- When HttpServletRequest.changeSessionId() is called and changes the session 
>ID, OR the container authenticates a request and 
>changeSessionIdOnAuthentication is enabled resulting in the session ID 
>>changing, OR a session ID is changed on one node in a cluster and it notifies 
>the other nodes to do the same, or a session ID is changed for any other 
>reason, HttpSessionIdListeners should be notified.
>
>- When HttpServletRequest.changeSessionId() is called and changes the session 
>Id, Context.fireContainerEvent() should be called with 
>Context.CHANGE_SESSION_ID_EVENT just like if the session ID were changed some 
>other way.
>
>Does anyone disagree with this?

With the above assumptions that I believe are correct, I have completed the 
changes necessary for this to work. It is compiling and running without any 
issues that I can see on my machine, I can successfully change a session ID by 
calling HttpServletRequest.changeSessionId(), and HttpSessionIdListeners are 
notified when I change a session ID. Everything appears to be working perfectly.

I tried to run all of the Junit tests locally, but when it completed 30 minutes 
later I had dozens of failures and dozens of errors. After reviewing the 
messages carefully, I am 99.9% sure that none of these are due to changes I 
made. I don't think I have my local environment set up right to run unit tests. 
(I would appreciate some guidance on this if anyone has any.) The majority of 
the failures were due to "java.lang.ClassNotFoundException: 
org.apache.tomcat.util.http.ValuesEnumerator." I am quite comfortable saying I 
didn't cause that, but I'm certainly not sure what did.

I have attached a diff file for my changes, which I'm not sure will get through 
because I don't know whether the developer's list allows attachments. I know 
the user's list doesn't. But seeing as how this is new development (Servlet 
3.1) and not a bug, I didn't have anything else to attach the diff on.

I'd appreciate feedback on the diff and any information anyone has about next 
steps.

This e-mail may contain privileged or confidential information. If you are not 
the intended recipient: (1) you may not disclose, use, distribute, copy or rely 
upon this message or attachment(s); and (2) please notify the sender by reply 
e-mail, and then delete this message and its attachment(s). Underwriters 
Laboratories Inc. and its affiliates disclaim all liability for any errors, 
omissions, corruption or virus in this message or any attachments.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to