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]
