tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 38290] New: - No SESSION_DESTROYED_EVENT sent for existing webapp sessions when webapp is reloaded
Date Mon, 16 Jan 2006 15:52:33 GMT
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: rdf@o2.co.uk


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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message