We never configure the HttpSessionBindingListener & HttpSessionActivationListener in the deployment descriptor.
The servlet container calls methods on an object implementing this interface only if that object is added to or removed from a session.
It is possible to monitor the activation and passivation of session via the HttpSessionActivationListener. We always implement this interface in a listener class to track session migration events i.e. activation or passivation.
SCJP 1.4 | SCWCD 1.4 | SCBCD 1.3 | SCEA Part I - Preparing..
Classes implementing interfaces other than HttpSessionBindingListener and HttpSessionActivationListener need to be declared in DD.
OK, I understand. But I have one question: if the HttpSessionActivationListener is implemented by some *other* class than an attribute class of which objects are bound to a session (as in HFSJ p.262)... then shouldn't the HttpSessionActivationListener be registered in the DD? In other words, never for attribute classes but still for other classes since the container would not "detect" objects of these classes.
This is not the purpose of HttpSessionActivationListener. This interface is used for session objects which need to be notified when a session if migrated. Objects not in session do not need to be notified, because they don't care about the session being migrated.
I think that what the container does is : 1. Get the session which is about to be migrated (HttpSession) 2. Get all attributes in that session (getAttributeNames) 3. Loop through each attribute and check if it is an instance of HttpSessionActivationListener 4. If it is, cast the object to HttpSessionActivationListener and call sessionWillPassivate/sessionDidActivate
(I can't tell about p262 because I don't own the book)
From the API:
Containers must notify any session attributes implementing the HttpSessionActivationListener during migration of a session. They must notify listeners of passivation prior to serialization of a session, and of activation after deserialization of a session.
When container migrates a session between VMs in a distributed container setting, all session attributes implementing the HttpSessionActivationListener interface are notified.
Objects that are bound to a session may listen to container events notifying them that sessions will be passivated and that session will be activated. A container that migrates session between VMs or persists sessions is required to notify all attributes bound to sessions implementing HttpSessionActivationListener.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com