*HttpSessionActivationListener* AND *HttpSessionBindingListener* must not be registered in deployment descriptor, instead, they are implemented by session attribute objects.
Here is what specification says :
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.
So, you can see - attributes themselves implement this interface, attributes are listenes, not some special class, which configured via DD.
public interface HttpSessionActivationListener extends java.util.EventListener
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.
Notifying Objects That Are Associated with a Session
Recall that your application can notify Web context and session listener objects of servlet life cycle events (Handling Servlet Life Cycle Events).
You can also notify objects of certain events related to their association with a session such as the following:
- When the object is added to or removed from a session. To receive this notification, your object must implement the javax.http.HttpSessionBindingListener interface. - When the session to which the object is attached will be passivated or activated. A session will be passivated or activated when it is moved between virtual machines or saved to and restored from persistent storage. To receive this notification, your object must implement the javax.http.HttpSessionActivationListener interface.
P.S. I do not have a HF S & JSP book, so can not say on the page 261.
P.P.S. The purpose of this interface - to allow object (a.k.a. session attribute) store himself in some persistent storage (like DB, or serialize on disk) and later allow to restore himself. I don't see any sense to delegate this to different class (a.k.a. listener configured in DD) for the following reason: 1) (many listeners for each type) if you have 10 types of object potentially stored in session - you have to configure them in DD, whenever object of new type is added - change DD is necessary. 2) (single listener for all types) separate listener can not get access to object itself - note interface privides only 2 new methods with only session as argument. how separate listener supposed to store object in persistent place?
Joined: Sep 30, 2003
I check servlet special yesterday before I post that. now I wrie a progrom to test it. You are right. HttpSessionActivationListener don't need to register in DD. Thank you to clear that.
that was an interesting thread... coz when i read HFSJ i thought that i need to register HttpSessionActivationListener in the DD.. but when i did some questions it seem the other way.. but i think i have cleared all my doubts now... so let me summarise what i learnt... and please point out if i'm wrong...