DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38290>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38290 Summary: No SESSION_DESTROYED_EVENT sent for existing webapp sessions when webapp is reloaded Product: Tomcat 5 Version: 5.0.28 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I'm writing a single sign-on (SSO) filter for Tomcat 5.0, which adds itself as a listener for HTTP session (org.apache.catalina.Session) objects. It relies on receiving SessionEvents so that when a session times out, it can be removed from the corresponding single sign-on session (and if the SSO session then contains no HTTP sessions, the whole SSO session itself should be destroyed). If a webapp is accessed (creating a new HTTP session), and the webapp is then redeployed (either while the session is still active, or after it becomes invalid but before the StandardManager removes it, the old Session object is "forgotten" and no SessionEvent is sent to my SessionListener. If the webapp is redeployed while the session is still valid, and the webapp is then refreshed in the browser, a new Session object for the same session ID is created. If the webapp is redeployed after the session has become invalid, but before the StandardManager cleans it up, and the webapp is then refreshed, a new Session object for a *new* session ID is created. In both cases, I receive no SessionEvent for the old, "forgotten" Session object, whereas the new Session object is treated normally, and times out, is cleaned up by the StandardManager, and so on. I may be missing something with regards to how Tomcat is supposed to clean up invalid sessions, but I would expect a SESSION_DESTROYED_EVENT to be sent to all SessionListeners when a Session object is invalidated due to the webapp being reloaded. The Java Servlet Specification mentions that when webapps are reloaded "the container should provide a robust approach to preserving session data within that application". Particularly in the second case, where a new session ID is created without properly destroying the old one, Tomcat doesn't seem to conform to the spec. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
