DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16822>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16822 StandardSession.setId() found incohesive Summary: StandardSession.setId() found incohesive Product: Tomcat 4 Version: 4.1.18 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] OBSERVED BEHAVIOR: ManagerBase.createSession() calls StandardSession.setId() as the last thing it does before returning a newly created session. StandardSession.setId() exhibits the undocumented side effect of firing a session creation event, iterating over all HttpSessionListeners registered with the current web context and notifying them of its "creation". A second call to setId() will again fire a session creation event for the existing session. Here's some trace from making a single request when calling setId() explicitly: 2003-02-03 17:46:43,113 [Ajp13Processor[17025][4]] INFO default - Adding session org.apache.catalina.session.StandardSessionFacade@4977e2 with id of 2EA4840C7D4D6C7F3FF76F1F95C575D5 2003-02-03 17:46:43,175 [Ajp13Processor[17025][4]] INFO default - Adding session org.apache.catalina.session.StandardSessionFacade@4977e2 with id of C6C908E127E6230CC81AE70E10D914A4 My web application's list of active sessions (stored as a Map of StandardSessionFacade objects keyed by session ID) will look as follows: Session creation event fired as ManagerBase sets the initial ID by calling StandardSession.setId() during its createSession() method | | v .______________________________________. | Key | Value | `--------------------------------------' | ID A | Facade A --> Session A (ID A) | `--------------------------------------' | | Second session creation event fired as SessionIdValve resets the ID, calling setId() for a second time (this time explicitly). | | v .______________________________________. | Key | Value | `--------------------------------------' | ID A | Facade A --> Session A (ID A) | | ID B | Facade A --> Session A (ID B) | `--------------------------------------' The entry keyed by session ID A will not be removed from our list of active sessions when Session A expires, as the session now has an ID of B. USE CASE: When creating a new session, I must set the session identifier (or manipulate it after the initial generation from a Valve) using request-specific inputs. Specifically, I must re-use any session identifier supplied by the client via its JSESSIONID cookie if that session identifier is not already in use. Because the Servlet API dictates that the session cookie is always named JSESSIONID, this is a must have for support of wildcard cookie domains across hosts which share a common base domain name. For instance, if I have host1.domain.com and host2.domain.com, and set the cookie domain of sessions cookie to the wildcard ".domain.com" (some pathetic browsers only support two part wildcard domains), the cookie will apply to both hosts. This is problematic when a client which has established a session on host1 tries to establish a second session on host2 -- host2 will assign the client a new session ID, wiping the client's memory of its session ID for host1. Now, if host1 and host2 are gracious enough to use the same session ID, they can effectively share the JSESSIONID cookie, allowing the client to enjoy simultaneous sessions on both host1 and host2 while working within the Servlet API. PROBLEM: Tomcat's Manager interface has no API for accessing contextual information specific to a request. Combining a Valve which provides this request-specific context via thread-local storage with my own custom manager is hacky at best, and would require that I completely re-implement the code in StandardSession (due to its package-private scoping). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]