The following is the sequence of things that happen when you invalidate a session:
1. Container calls sessionDestroyed() on all HttpSessionListeners configured in web.xml (in the reverse order they are declared in web.xml). Notice that although the method name is sessionDestroyed, the session is not destroyed yet. It is about to be destroyed. (Note that sessionCreated is called on the listeners in the order they are declared in web.xml)
2. The container destroys the session.
3. The container calls valueUnbound() on all the session attributes that implement HttpSessionBindinglistener interface.
There is getSession() method in HttpSessionEvent Class used to obtain the seesion that caused such a change, and this method is inherited by HttpSessionBindingEvent,
if HttpSeesionBindingLiseners valueUnbound is caled after session is destroyed, what is the result of calling getSession() from there.
If it's still in your mind, It is worth taking the risk !!
Arch enemy? I mean, I don't like you, but I don't think you qualify as "arch enemy". Here, try this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!