Community
Participate
Working Groups
Build Identifier: According to the servlet spec: "A container that migrates session between VMs or persists sessions is required to notify all attributes bound to sessions implementing HttpSessionActivationListener." And: "public void sessionWillPassivate(HttpSessionEvent se): Notification that the session is about to be passivated." Although the spec might not be 100% specific about it, I think the container should call sessionWillPassivate before a session is persisted. Jan Bartel also supports this view on jetty-dev: "Hhhmm, I think that's a bug. We really should call willPassivate() before the objects are written out. This will need some refactoring of the AbstractSessionManager to accommodate the HashSessionManager's doStop() behaviour. The listeners are actually called by AbstractSessionManager.doStop() which removes each of the sessions and then calls the willPassivate() - in that order." Given a rough todo-list and some hand holding I could attempt writing a patch for this. Otherwise, I'll leave it to the gurus :-) Reproducible: Always Steps to Reproduce: 1. Leave a non-serializable attribute in the session 2. Have a HttpSessionActivationListener remove the attribute on sessionWillPassivate 3. Confirm that an exception is thrown during serialization, before sessionWillPassivate is called
Looking at this a little closer, I can't see Jetty ever calling willPassivate on a session in the current HashSessionManager since it's protected by an if(!invalidate) and invalidate seems to be true always.
Created attachment 175557 [details] Test webapp which demonstrates that sessionWillPassivate is never called Simple webapp used for demonstrating HttpSessionActivationListeners being not being called before serialization. Or actually not being called at all.
So I'm going to commit a patch that calls willPassivate before is saves sessions and didActivate after it restores sessions. But it is a truly horrible specification... we can run in a mode where we save a session periodically - so we will now call willPassivate before the save and didActivate after the save. But there is no locking to prevent other requests hitting the session during this time. Likewise, after a session is restored, there is nothing to prevent other requests hitting the session before didActivate is called. I'm just running some tests to confirm I've not broken anything, then I will commit.
jetty-7.2.0.RC0 1 October 2010
