I defined pathname="" in the Manager tag, because I did not want to continue sessions even if my application(or tomcat) is reactivated. As a result, sessions are not stored in the file "SESSIONS.ser", but HttpSessionListener#sessionDestroyed is not called. I think following logic is the cause: --- ...In StandardContext#stop() // Stop our filters filterStop(); // Stop our application listeners listenerStop(); // Stop ContainerBackgroundProcessor thread super.threadStop(); if ((manager != null) && (manager instanceof Lifecycle)) { ((Lifecycle) manager).stop(); } --- I think it would be better that listenerStop() is called after manager#stop(), or that we do not set null to applicationLifecycleListenersObjects in listenerStop() method at least for the HttpSessionListener instance.
The code you quoted is not the root cause of this behaviour. The root cause can be found at line 483 of http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/StandardManager.java?revision=466608&view=markup As far as I can see, the spec is silent on what should happen in this case. I am going to mark this as an enhancement request and start a discussion on the dev list as to what, if anything, Tomcat should do in this case.
The conclusion from the discussion on the dev list was: - this change would be acceptable - it must be configurable - the default behaviour must be the current behaviour I'll come back to this later. In the meantime, you can always implement your own Manager that extends StandardManager and overrides doUnload(). If you need help to do this, please ask on the users list.
Thanks Mark for the discussion. O.K, I will use my own Manager for the time being until you return. Regards. Yuichiro
I have tried but I could't solve this problem. The problem is that the listener is already stopped when doUnload is called. So I think we have no way to call listener's method from doUnload(or manager.stop). The other way is using my own Context that extends StandardContext and overrides stop(), however I think it is not so good way.
Either Mark or Suzuki: did you ever develop a patch for this? If so, please attach it to this item (or in Mark's case, just commit it). I'll be glad to review it.
I have seen that tomcat 6 the listenerStop() calls after manager.stop(). I vote to change it also at tomcat 5.5 codebase. Peter (In reply to comment #5) > Either Mark or Suzuki: did you ever develop a patch for this? If so, please > attach it to this item (or in Mark's case, just commit it). I'll be glad to > review it.
Created attachment 19810 [details] tomcat5 patch for StandardContext calling listenerStop() after manager.stop()
Thanks Peter. I don't have good idea besides calling listenerStop() after manager.stop() same as Tomcat6. It is so simple, but I attached the patch. yuichiro
Fix with revision 522870 at tomcat 5.5 trunk. Thanks for your patch. Peter