permaculture playing cards
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes 2 Listeners - No need to configure in DD Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "2 Listeners - No need to configure in DD" Watch "2 Listeners - No need to configure in DD" New topic

2 Listeners - No need to configure in DD

Sandeep Vaid
Ranch Hand

Joined: Feb 27, 2006
Posts: 392
You don't have to register HttpSessionBindingListener & HttpSessionActivationListener in DD.

Is this statement correct ?
Christophe Verré

Joined: Nov 24, 2005
Posts: 14688

[My Blog]
All roads lead to JavaRanch
Mahesh Desai
Ranch Hand

Joined: Apr 04, 2007
Posts: 76
Hi Sandeep,

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..
Yves J Thorrez

Joined: Apr 24, 2007
Posts: 3
From the FAQ:

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.

Christophe Verré

Joined: Nov 24, 2005
Posts: 14688

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 agree. Here's the link:
subject: 2 Listeners - No need to configure in DD
jQuery in Action, 3rd edition