HttpSessionActivationListener is also configurable in the DD. You can configure it in the DD if you want to listen for when a session migrates to another VM. It can also be implemented by a session attribute class to prepare the attribute for the migration.
I don't think that is correct. According to the book of Sun Certified Web Component Developer Study Guide (by David Bridgewater) it is not like that:
Now we move on to two other session-related listeners which are different in character
to the listeners we have previously encountered, whether on session, request, or
context. These listeners are:
Classes implementing these listener interfaces are not declared in the deployment
descriptor. They become known to the web container through a different mechanism
I checked the servlet 2.4 specs and it also confirms this
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.
because they don't mention the phrase:
To receive notification events, the implementation
class must be configured in the deployment descriptor for the web application
I'm reading the Head First Servlets and JSP book and it says that it can go both ways. It says that it's used when
You want to know when a session attribute has been added, removed, or replaced (p.182).
and also when
You want to know when a session moves from one VM to another (p.264).
In an exercise (p.264), it asks the reader to mark whether the listener is used on an attribute class or defined in the DD and HttpSessionActivationListener has checkmarks next to both. But I've never written a distributed Java web app, so I don't know for sure.