First B: for session.setAttribute("dab", new DealerAddrBean());
Next UB-> B: for session.setAttribute("dab", new DealerAddrBean()); As it is replacing the same attribute dab..
Next UB: for session.setAttribute("dab","x"); As it is removing existing DealerAddrBean (Unbind is called). Since it is not binding DealerAddrBean but its placing a string, no valueBound method is called.
session.removeAttribute("dab"); is not printing anything because it is removing attribute where value is String.. and it does not have valueUnbound() method.
Hope this helps you.
Joined: Sep 15, 2007
Swathi, yes thanks... that helps... that is in keeping with the answer I got when I tried it out.
Got you point Michael. Thanks a ton. (Guess I'm seeing double these days )I tried this using RAD and got BUBBUB.
Hmm So this is container dependent too....
Joined: Apr 20, 2002
Run it on Tomcat (which the book assumes that you do) and it comes out BBUBUB
This is definately container dependent. even i posted the same few days back...
it says that always Bound happens First and then unbound. if the value is replaced than first the new Value is Bound and then old Value is Unbound. Logically it doesn't seems to be the correct sequence but actually its like that. for example: if session is invalidated the sessionDestroyed of HttpSesssionListener is called first and after that valueUnbound of HttpBindingListener is called.
As per my perception the listeners are called earlier than the actual object is removed or added or replaced internally. thats y the sequence is irregular.
the simplest rule here that we got 2 DealerAddrBean objects & 1 String object , so the listener will work ONLY for the 2 DealerAddrBean objects, so when first time the obj bounded it will print "B" , same as second time , when the obj unbounded it will priint "UB", as we got 2 objects so it will be printed twice , So the finally nswer is : BBUBUB