Order of Listener Notification

[Vidya Sethuraman]

Hi,

In servlet spec 2.4, pg 82,
SRV.10.3.4 Notifications At Shutdown
On application shutdown, listeners 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.

If in DD, we define context lifecycle listener before a HttpSession listenerlistener, then how does the notification work?
During shutdown, which one is notified first?

Thanks!

[Christophe Verré]

HttpSession listener will be called first, in reverse order they were declared.

[Vidya Sethuraman]

Hi,

Thanks Satou.
What if i declare in the DD a session listener and a context listener in this order, then on application shutdown, how are the listeners notified?
Is it just reverse order or according to spec.
"Session listeners must be notified of session invalidations prior to context listeners being notified of application shutdown."

Thanks!

[Christophe Verré]

- session listeners first (in reverse order)
- then other listeners (in reverse order)

[Narendra Dhande]

Hi,

I partially agree with Satou. But I have some doughts in this sequence.

On application shutdown, listeners 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.

In the specification, on page 82, In Servlet registaration, the statement is like this

The Web container registers the listener instances according to the interfaces they implement and the order in which they appear in the deployment descriptor. During Web application execution, listeners are invoked in the order of their registration.

I think here is confusion in registartion and execution of the listeners. At the time of registering the event listeners the container register the listeners according to the type of the listerners. If there are more than one listener of the same type the container follow the DD order.

At the time of shutdown the container follow the order exactrly reverse to the registration. That means first the session listeners are de-registered and then context listerners. In the particular listener type if there are more than one listeners then it de-registered exacly in reverse order they registered.

The listeners are executed when the patricular event is occured.

The above is my understading about the Registration/execution of listeners.

Now I have two doughts in this sequence.

1. Where the Request Listeners fit in this sequence. After/Before Session Listeners.

2. At the time of shutdown, Does really the session listeners notified ? As per the seesion specification chapter, there are only two conditions when the session is invalidated one is time-out and other is programatic invalidation of the session. Some container store the information in presistant Beans or in database, so even the application server is shutdowned the session is not invalidated.

I appreciate if someone clarify this.

Thanks
[ March 23, 2006: Message edited by: Narendra Dhande ]

[Frederic Esnault]

The specification is very clear about this (even if sometimes it is said in a strange way ).

Explanation
During webapp life, the listeners are invoked in the order they are declared in the DD; no mistery there. If you have a list of listeners like the following one (S is for SessionwhateverListener, C is for ContextwhateverListener) :

C_Listener1

S_Listener1

S_Listener2

C_Listener2

S_Listener3

then when an event occurs, the container goes through this list, in this order, and calls matching listeners. Again, no mistery.

At application shutdown, the story changes. To explain what happens, let's imagine a small algorithm the container uses to reorder listeners, in order to be able to do the same processing as during webapp life ( go down the list and call each matching listener).
1. Container inverts the list order. The list becomes :

S_Listener3

C_Listener2

S_Listener2

C_Listener1

S_Listener1

2. Container sorts the list, assuming SListeners stands for 1, and CListeners stands for 2. The list becomes :

S_Listener3

S_Listener2

S_Listener1

C_Listener2

C_Listener1

Now the process is the same as during webapp life, and ensure webapp shutdown is safe.

Why such a process ?
For some classes in the servlet API, you have been told that they have container callback methods to manage their lifecycle (init, destroy). The reason for init method is to allow correct initialization before any request is served. The reason for destroy method is to allow the developer to free any resources the app can hold before the object is garbage collected.

The container always ensure that every components gets a chance to say goodbye and clean up its resources before getting rid of them. The same happens for webapp lifecycle.

The init and destroy methods of Servlet or Filter class can be compared to the Listeners' methods of the webapp. They ensure that : a session object has a chance to initialize itself before being used, and has a chance to say good bye before dying. The webapp itself has its init/destroy with the ServletContextListener.

Keeping this opening/closing enforcing policy, (like an XML parser would check for order of opening/closing tabs) the container closes nested components before the components holding them.

A webapp can be seen as a Context, and a session belongs to a context. With the philosophy I explained, it comes that before closing the webapp, the container closes any nested components, hence closes the Session before the webapp.

Logically, Listeners are called when the corresponding components are closed, and as we saw Session are closed before webapp, so SessionListeners are called BEFORE ContextListeners.

A bit long, but I hope it's clear.