This listener interface can be implemented in order to get notifications of changes to the attribute lists of sessions within this web application.
Causes an object to be notified when it is bound to or unbound from a session. The object is notified by an HttpSessionBindingEvent object. This may be as a result of a servlet programmer explicitly unbinding an attribute from a session, due to a session being invalidated, or due to a session timing out.
Originally posted by Chintan Rajyaguru:
If an object implements HttpSessionBindingListener, it is notified when it is bound to or unbound from a session. For example,
MyObject implements HttpSessionBindingListener
// class definition
If I call
session.setAttribute ("Object", MyObject)
session.removeute ("Object", MyObject)
and so on, methods valueBound and/or valueUnbound (defined in HttpSessionBindingListener, implemented in MyObject are called)
When any class implements HttpSessionAttributeListener interface it is notified when any change in the attribute list of session occurs. For example
MyClass implements HttpSessionAttributeListener
// implementations of methods
session.setAttribute ("anything", AnyObjectNotOnlyMyClass);
session.removeAttribute ("anything", AnyObjectNotOnlyMyClass);
indicates change in the list of attributes and hence appropriate method is called
Implementing HttpSessionBindingListener works only for the object that implements it whereas implementing HttpSessionAttributeListener listens to any attribute added, removed or replaced.
Hope this helps. This is important. Let me know if this is not clear, I will explain it again with simple words. I had questions from these topics.
[ January 04, 2002: Message edited by: Chintan Rajyaguru ]
Originally posted by Rohit Poddar:
Let me try to give an argument why do we have these two listener and let's see if I succeed
HttpSessionBindingListener was there before Servlet 2.3 came out. And HttpSessionAttributeListener, which serves a broader purpose was added in 2.3. And now to maintain backward compatibility Sun must have left HttpSessionBindingListener in there.
Any takers ?
[ January 10, 2002: Message edited by: Rohit Poddar ]
Originally posted by ersin eser:
I guess this separation might help while decoupling the dependencies ? I think you can make you pool class implement binding listener and let it take care of the business ( maintanence, reclaims etc by itself ) Looks like in attributeListener you are going to need lots of instanceof checks thus way too much dependencies might be created.
Any input ?
[ January 11, 2002: Message edited by: ersin eser ]