Bug 40593 - HttpSessionListener#sessionDestroyed is not called though the manager's pathname is emply.
HttpSessionListener#sessionDestroyed is not called though the manager's pathn...
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Catalina
Nightly Build
PC Windows XP
: P2 enhancement (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-09-24 07:54 UTC by Suzuki Yuichiro
Modified: 2007-03-27 04:39 UTC (History)
0 users



Attachments
tomcat5 patch for StandardContext calling listenerStop() after manager.stop() (824 bytes, patch)
2007-03-27 00:29 UTC, Suzuki Yuichiro
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Suzuki Yuichiro 2006-09-24 07:54:23 UTC
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.
Comment 1 Mark Thomas 2006-11-25 08:32:44 UTC
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.
Comment 2 Mark Thomas 2006-11-26 07:22:54 UTC
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.
Comment 3 Suzuki Yuichiro 2007-01-20 05:24:23 UTC
Thanks Mark for the discussion.

O.K, I will use my own Manager for the time being until you return.

Regards.
Yuichiro
Comment 4 Suzuki Yuichiro 2007-02-13 23:02:21 UTC
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.
Comment 5 Yoav Shapira 2007-03-25 09:04:02 UTC
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.
Comment 6 Peter Rossbach 2007-03-26 10:42:32 UTC
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.
Comment 7 Suzuki Yuichiro 2007-03-27 00:29:51 UTC
Created attachment 19810 [details]
tomcat5 patch for StandardContext calling listenerStop() after manager.stop()
Comment 8 Suzuki Yuichiro 2007-03-27 00:31:00 UTC
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
Comment 9 Peter Rossbach 2007-03-27 04:39:03 UTC
Fix with revision 522870 at tomcat 5.5 trunk.

Thanks for your patch.
Peter