This is probably the bug you're talking about. http://issues.apache.org/bugzilla/show_bug.cgi?id=29521
On Fri, 2004-12-10 at 04:19, Steve Kirk wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
