Sessionm Listener not notified when Tomcat shutdown

Hi,
Have anyone of u encountered this:
The Servlet 2.3 spec says
"On application shutdown, listners are notified in reverse order to their declarations with notifications to session listeners preceeding notifications to context listeners. Session listeners must be notified of session invalidations prior to context listeners being notified of application shutdown."
I have tried declaring a session listner (implements HttpSessonListener) and a context listner in the deployment descriptor in TOMCAT 4.0.1. However, the session listner is not notified when I shut down the server. Seems like the session is not being invalidated during the shutdown.
Please let me know whether there is something wrong with Tomcat or my understanding is wrong.
Thanks.

Hi - You are correct in stating that TC does not call sessionDestroyed() during shutdown.
The wording in the spec is ... interesting.
I am still trying to decide whether I think TC is out of spec or not.
Regards, Guy
Later - OK, after some experiments, what TC does do is 'persist' sessions across a shutdown-startup sequence.
sessionDestroyed() will be called after a new startup at an appropriate time for that session (i.e. depends on session-timeout value when session was created).
I am still cruising the directories to find out where TC saves this data.
Is it according to spec? Still thinking.
G.
And later still - after more experiments.
After TC shutdown but before restart there will be a file:
$CATALINA_HOME/work/localhost/<context-root>/SESSIONS.ser
It is a 'binary' file, but it is where TC saves session timeout information.
This file is read on startup, and deleted, so you will not see it if TC is running.
Is this behavior according to spec? I am leaning towards 'no', but would like to hear from other folks on this forum!
G.
And even later yet - I changed my mind. TC is in spec. You are being notified of session invalidation. It just does not occur when you expected it to. The specs do not say anything about timing.
G.
[ March 14, 2002: Message edited by: Guy Allard ]