I have answered one of the points below myself with more testing: HttpSessionActivationListener#sessionWillPassivate seems to work slightly different to the other Listeners in that its methods are only called when they are an object bound to the session is an instance of the HttpSessionActivationListener. The javadocs actually do say this, but I didn't take it in at first: "Objects that are bound to a session may listen to container events notifying them that sessions will be passivated and that session will be activated. A container that migrates session between VMs or persists sessions is required to notify all attributes bound to sessions implementing HttpSessionActivationListener."
Thus HttpSessionActivationListener works slightly differently to HttpSessionListener for example, because the latter's sessionCreated and sessionDestroyed methods are called irrespective of whether they are methods of objects bound within the session or not. However I'd still appreciate any help that anyone can give on the other points below :) > -----Original Message----- > From: Steve Kirk [mailto:[EMAIL PROTECTED] > Sent: Friday 10 December 2004 05:50 > To: 'Tomcat Users List' > Subject: RE: sessionS info persistence when restart Tomcat > > > > OK well after a few weeks' break from it I've returned to > this problem with > fresh eyes, and immediately found out something interesting. > > I normally run TC (5.0.28) as a windows service. So upon > re-reading this > thread, Yoav's earlier comment stood out as something I > hadn't checked, so I > ran TC using the startup and shutdown scripts instead. I > have a simple test > class which listens for the context/session events and logs > them. This > shows that the following things happen when running from the > DOS scripts, > which do not happen when running as a service: > > contextDestroyed is called when TC shuts down > sessions are serialised to SESSIONS.ser when TC is stopped > java.io.NotSerializableException is thrown when a session > object is not > serializable > > So I guess Yoav's point below from earlier in the thread > could be correct > after all - these could be outstanding bugs. However I couldn't find > anything in Bugzilla. > > A second point is that > HttpSessionActivationListener#sessionWillPassivate is > still not being called, even when start/stopping TC from the > DOS scripts, > and whether or not there are any object stored in the session > (I store a > simple String in the session for test purposes). I can't think what's > wrong, unless I am using HttpSessionActivationListener > incorrectly? I have > just added it as another interface implemented by my Listener > class along > with the other Listener interfaces (HttpSessionListener, > HttpSessionAttributeListener, ServletContextListener), is > this correct? > > A third point (and perhaps wandering slightly now) is raised > by the logged > NotSerializiableException message: > > INFO: Cannot serialize session attribute LOGGED_IN_USER for session > 58FD0ECF29BDCEB9DC096C5DF57A1DCC > java.io.NotSerializableException: core.servlet.processor.SubmitLogin > at > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) > > this message is odd in that it refers to one of my classes > ("SubmitLogin") > which, to my mind, has nothing to do with serialisation > issues. What does > the error message mean when it quotes my class name > (core.servlet.processor.SubmitLogin) as the error message? I > know that this > is certainly *not* the class of any object stored in the > session - I have > checked this from my event listening class's logs - I write > all the session > attributes to the log as each one is added. > > Obviously I need to fix my unserialisable session object, but > aside from > that, it does seem from all the above as though session events and > exceptions are handled differently when TC runs as a windows service > compared to from the DOS scripts. Also I have the problem that > sessionWillPassivate still does not seem to be called. > > Any help much appreciated :) > > > -----Original Message----- > > From: Ben Souther [mailto:[EMAIL PROTECTED] > > Sent: Friday 05 November 2004 14:52 > > To: Tomcat Users List > > Subject: RE: sessionS info persistence when restart Tomcat > > > > > > On Fri, 2004-11-05 at 08:29, Shapira, Yoav wrote: > > > Hi, > > > Are you running Tomcat as a windows service? If so > there's an open > > > issue with it not calling certain destroy methods on shutdown. > > > > > > Yoav Shapira http://www.yoavshapira.com > > I believe that issue was with contextDestroyed not being > > called and was > > tested under 5.0.8 and 5.5.x and working. > > > > > > > > >-----Original Message----- > > > >From: Ben Souther [mailto:[EMAIL PROTECTED] > > > >Sent: Thursday, November 04, 2004 9:22 PM > > > >To: Tomcat Users List > > > >Subject: RE: sessionS info persistence when restart Tomcat > > > > > > > >SessionDestroyed shouldn't be called when tomcat shuts > > down. Otherwise, > > > >the session wouldn't be valid when it starts up. I just > > tested with a > > > >clean install of 5.0.29 with a similar listener to the one you > > > describe. > > > >SessionDestroyed was not called when I stopped TC but the > > sessions were > > > >still valid when I started it up. I can give you the war > > file if you > > > >like. > > > > > > > >Do all of the attributes that you're adding to your > > session implement > > > >Serializable? > > > > > > > >> > > > C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The > > > >>system cannot find the path specified) > > > >Does tomcat have sufficient permissions to write to the > > work directory? > > > > > > > >How are you stopping Tomcat? > > > > > > > > > > > > > > > >On Thu, 2004-11-04 at 20:15, Steve Kirk wrote: > > > >> Following Yoav's earlier comments I've implemented a > basic class > > > >> "SessionLogger" that implements HttpSessionListener, > > > >> HttpSessionActivationListener, HttpSessionAttributeListener, > > > >> ServletContextListener. It just writes amessages to > stdout using > > > >> System.out.println() to log when each event fires, > > including each of > > > the > > > >> interface events plus instantiation and finalization of > > SessionLogger > > > >> itself. I've configured it in web.xml: > > > >> > > > >> <listener> > > > >> > <listener-class>core.servlet.SessionLogger</listener-class> > > > >> </listener> > > > >> > > > >> SessionLogger logs its own presence OK when I > instantiate it, and > > > happily > > > >> logs events as expected on sessions, and session > > attributes. It logs > > > >> context creation but not destruction. Here's some sample > > > catalina.log > > > >lines > > > >> for starting TC, logging in, logging out, logging in again: > > > >> > > > >> 2004-11-05 00:56:50 StandardContext[/ao]*** SERVLET CONTEXT: > > > initialized > > > >> 2004-11-05 00:58:08 StandardContext[/ao]*** SESSION EVENT: > > > >sessionCreated, > > > >> [EMAIL PROTECTED] > > > >> 2004-11-05 00:58:23 StandardContext[/ao]*** SESSION > > ATTRIBUTE EVENT: > > > >> attributeAdded, LOGGED_IN_USER, [ID=1] > > > >> 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION > > ATTRIBUTE EVENT: > > > >> attributeRemoved, LOGGED_IN_USER, [ID=1] > > > >> 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT: > > > >sessionDestroyed, > > > >> [EMAIL PROTECTED] > > > >> 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT: > > > >sessionCreated, > > > >> [EMAIL PROTECTED] > > > >> 2004-11-05 00:58:34 StandardContext[/ao]*** SESSION > > ATTRIBUTE EVENT: > > > >> attributeAdded, LOGGED_IN_USER, [ID=1] > > > >> > > > >> However if I then stop TC, I get nothing logged at all > after the > > > >> "attributeAdded" event. The log just shows this as the > > last line: > > > >> > > > >> 05-Nov-2004 00:03:57 > > org.apache.coyote.http11.Http11Protocol pause > > > INFO: > > > >> Pausing Coyote HTTP/1.1 on http-80 > > > >> > > > >> and there are no loglines to indicate that the > > > >> SessionLogger#sessionDestroyed, > SessionLogger#contextDestroyed or > > > >> SessionLogger#finalize methods were called. > > > >> > > > >> So it looks like sessions are working, but something is > > not working > > > when > > > >TC > > > >> stops, and I suspect that this is why my sessions don't > > persist over > > > >> restarts. I've read the docs and how-tos that I can find, plus > > > googled > > > >> forum stuff on the web. Does anyone have any insights please? > > > >> > > > >> PS the above applies whether or not I explicitly add a > > Manager to my > > > >context > > > >> config. Note that the standard config files for 5.0.28 do not > > > explictly > > > >> include a <Manager>, but the docs say that "A Manager > > element MAY be > > > >nested > > > >> inside a Context component. If it is not included, a > > default Manager > > > >> configuration will be created automatically". I tried adding a > > > Manager > > > >to > > > >> my context as follows just in case following Yoav's > > earlier comments: > > > >> <Manager > className="org.apache.catalina.session.StandardManager" > > > >> distributable="false" debug="4" pathname="SESSIONS.ser" /> > > > >> but this made no difference to the behaviour described above. > > > >> > > > >> Another weird thing: if I trigger a webapp reload by > > rebuilding my > > > >warfile > > > >> while TC is running, TC complains about the absence of > > SESSIONS.ser - > > > it > > > >> appears to be trying to persist sessions to the file - > > which it does > > > not > > > >try > > > >> to do when I stop TC. The log message is: > > > >> > > > >> 05-Nov-2004 00:23:26 > org.apache.catalina.session.StandardManager > > > doUnload > > > >> SEVERE: IOException while saving persisted sessions: > > > >> java.io.FileNotFoundException: > > > >> > > > C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The > > > >system > > > >> cannot find the path specified) > > > >> > > > >> The file does not exist so the message sort of makes > > sense, except > > > that > > > >this > > > >> does not happen if I stop and then start TC again - only > > if a reload > > > is > > > >> triggered when I rebuild my warfile. > > > >> > > > >> > -----Original Message----- > > > >> > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > > > >> > Sent: Thursday 04 November 2004 16:09 > > > >> > To: Tomcat Users List > > > >> > Subject: RE: sessionS info persistence when restart Tomcat > > > >> > > > > >> > > > > >> > > > > >> > Hi, > > > >> > > > > >> > >I had always thought all sessions were lost when the server > > > restarts. > > > >> > In > > > >> > >fact I just tried it and confirmed that (5.0.28). Are we > > > >> > maybe talking > > > >> > >about 2 different things? > > > >> > > > > >> > I think we're talking about the same thing. Sessions are > > > >> > supposed to be > > > >> > persisted by default. > > > >> > > > > >> > >I have nonstandard config (a very sparse server.xml, > > no explicit > > > >> > Manager > > > >> > > > > >> > You need a Manager. When I said "by default" I mean > out of the > > > box, > > > >> > i.e. with the default server.xml, which has such a > > Manager IIRC. > > > >> > > > > >> > >Is this the manager config ref you were talking about? > > > >> > > > > > >http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html > > > >> > > > > >> > Yeah. > > > >> > > > > >> > >I just read through it. If I've understood > > correctly, because my > > > >> > Manager > > > >> > >is > > > >> > >not explicitly configured, > > > >> > > > > >> > There's a difference between not explicitly configured and > > > >> > not declared > > > >> > at all. > > > >> > > > > >> > One way to test this is with an > > > >> > HttpSessionListener/HttpSessionActivationListener (one > > listener can > > > >> > implement both interfaces and thereby capture all four > > > >> > relevant events). > > > >> > It's trivial to write one that just prints out information > > > >> > when sessions > > > >> > are created, destroyed, passivated, and activated. > > > >> > > > > >> > Yoav > > > >> > > > > >> > > > > >> > > > > >> > This e-mail, including any attachments, is a confidential > > > >> > business communication, and may contain information that is > > > >> > confidential, proprietary and/or privileged. This e-mail is > > > >> > intended only for the individual(s) to whom it is addressed, > > > >> > and may not be saved, copied, printed, disclosed or used by > > > >> > anyone else. If you are not the(an) intended recipient, > > > >> > please immediately delete this e-mail from your computer > > > >> > system and notify the sender. Thank you. > > > >> > > > > >> > > > > >> > > > > > > > --------------------------------------------------------------------- > > > >> > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > >> > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > > --------------------------------------------------------------------- > > > >> To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > >> For additional commands, e-mail: > > [EMAIL PROTECTED] > > > >> > > > >> > > > > > > > > > > > > > > >--------------------------------------------------------------------- > > > >To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > >For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > This e-mail, including any attachments, is a confidential > > business communication, and may contain information that is > > confidential, proprietary and/or privileged. This e-mail is > > intended only for the individual(s) to whom it is addressed, > > and may not be saved, copied, printed, disclosed or used by > > anyone else. If you are not the(an) intended recipient, > > please immediately delete this e-mail from your computer > > system and notify the sender. Thank you. > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
