Thanks Ben, have looked at your war, and my test code covers the same as yours plus some of the other Listener events. The sessionCreated and sessionDestroyed events work fine on my code (5.0.28). The problem is that the other events I mentioned are not called - e.g. contextDestroyed.
> If your object (or any of the objects contained within it) are not > serializable) tomcat will quietly not save it. ok that's interesting and perhaps a little surprising given that the docs say that they MUST be. I've also tried adding the distributable attribute to the webapp as indicated here http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html#Restart% 20Persistence to see if that causes stricter behaviour (e.g. throwing an exception when TC tries to serialize session objects), but this appears to make no difference in my situation. > try creating a real simple object that implements Serializable and see > if it survives a restart. In effect I have already done that by restarting TC, then browsing webapp pages as a user that does not log in. In this case I do not assign any objects to the session (I have checked this using session.getAttributeNames in my SessionLogger to check that there are none). Even in this case TC does not serialize to SESSIONS.ser on shutdown. So I don't think that the problem is serialisability....? Also, still can't work out why SESSIONS.ser is only accessed when a new warfile causes a reload and not otherwise. > -----Original Message----- > From: Ben Souther [mailto:[EMAIL PROTECTED] > Sent: Friday 05 November 2004 15:08 > To: Tomcat Users List > Subject: RE: sessionS info persistence when restart Tomcat > > > On Fri, 2004-11-05 at 09:06, Steve Kirk wrote: > > > SessionDestroyed shouldn't be called when tomcat shuts down. > > > > good point. doh! but if I've understood correctly, > shouldn't other methods > > of my SessionLogger be called? namely sessionWillPassivate, > > contextDestroyed (and possibly finalize although I'm not > 100% confident of > > that). > contextDestroyed does get called when you shut down tomcat. I > don't know > about sessionWillPassivate. > > > > > > 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. > > > > yes please. email it to me off list if you prefer. > > You can grab it here: > http://www.souther.us/sessionTest.war > > I ran it in a clean install of TC5.0.29. > There are two jsps and a sessionListener. > test.jsp shows you the current sessionID. > kill.jsp invalidates the session. > The session listener prints to stdout (catalina.out) > when a session is created or destroyed. > > I was able to stop and restart TC and maintain the same session. > sessionDestroyed was not called. > > You could easily add to it to test for sessionWillPassivate(). > > > > > > > > > > Do all of the attributes that you're adding to your > session implement > > > Serializable? > > > > I did spot that issue late on just before my last post. So > I checked and > > only one object is ever stored in the session - a "User" > class of my own. > > Its fields are all of type String, java.sql.Timestamp or > int. I added > > "implements Serializable" to it (I think this is all that > was required?) but > > this made no difference. Also, I have tried stopping TC > when a session has > > been created but *no* attributes have been added to it, and > the problem is > > the same. > > > > In any case though, if serialisation was the problem, > shouldn't I see some > > kind of error message from TC along the lines that it > cannot serialise an > > object in a session? Also I can't work out why it only > complains that it > > can't find SESSIONS.ser when it reloads the webapp? > > > If your object (or any of the objects contained within it) are not > serializable) tomcat will quietly not save it. > > try creating a real simple object that implements Serializable and see > if it survives a restart. > > -Ben > > > > > --------------------------------------------------------------------- > 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]
