Mmmh, I'm not sure about this. As the API says, 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.. What's the point in registering such a listener in web.xml ? Only objects in the session implementing this interface will be notified.
If it's not associated to any session object, I can't see why the container would call it. I persist to say that it's no use to register it, and that it won't be called The API also states that a container that migrates session between VMs or persists sessions is required to notify all attributes bound to sessions implementing HttpSessionActivationListener.. I'd like to try it though.
As far as these two listeners (HttpSessionActivationListener and HttpSessionBindingListener) are concerned, container can identify at runtime by using "instanceof" operator on attribute class which is going to associate with to session. So no need to specify in the web.xml.
But in case of other listeners, container has no information whether it exist or not in your web application so as you have to specify it in the web.xml.
Hope it will help!!!
Put the moon back where you found it! We need it for tides and poetry and stuff. Like this tiny ad: