Following Yoav's earlier comments I've implemented a basic class
"SessionLogger" that implements HttpSessionListener,
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:
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:
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:
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:
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:Yoav.Shapira@mpi....]
> Sent: Thursday 04 November 2004 16:09
> To: Tomcat Users List
> Subject: RE: sessionS info persistence when restart Tomcat
> >I had always thought all sessions were lost when the server restarts.
> >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
> 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 >
> >I just read through it. If I've understood correctly, because my
> >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.
> 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: tomcat-user-unsubscribe@jaka... > For additional commands, e-mail: tomcat-user-help@jaka... >