Bug 38242 - StandardSession.invalidate() Session Already Invalidated; removeAttributeInternal JNDIManager
Summary: StandardSession.invalidate() Session Already Invalidated; removeAttributeInte...
Status: RESOLVED DUPLICATE of bug 34107
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Webapps:Manager (show other bugs)
Version: 5.5.12
Hardware: Other other
: P2 critical (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-12 17:44 UTC by Rob Young
Modified: 2006-06-01 08:28 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rob Young 2006-01-12 17:44:00 UTC
On the class org.apache.catalina.session.StandardSession, method invalidate() it
calls expire() which flags the session as invalid; setValid(false), then in the
same expire method it calls removeAttributeInternal(keys[i], notify), this
method makes a method call of: ((HttpSessionBindingListener)
value).valueUnbound(event).    When the implementing class tries to call:
ttpSessionBindingEvent bindingEvent, bindingEvent.getSession().getId(); you get
a IllegalStateException, the Session is Already Invalidated.  This is caused
because the setValid(false) should be set at the end of the expire() method
after all objects are unbound.  The implementation example I am having the
problem with is on UPortal org.jasig.portal.jndi.JNDIManger.java class @Version
$Revision: 1.32, on the valueUnbound (HttpSessionBindingEvent bindingEvent) method.
Comment 1 Rob Young 2006-01-12 17:47:07 UTC
JBoss has implemented their ClusteredSession class correctly.  See
http://docs.jboss.org/jbossas/javadoc/4.0.2/org/jboss/web/tomcat/tc5/session/ClusteredSession.java.html

Take note of their expire() method, the setValid(false) is at the end of the method.
Comment 2 william.barker 2006-01-12 18:12:52 UTC

*** This bug has been marked as a duplicate of 34107 ***
Comment 3 Rob Young 2006-06-01 15:28:35 UTC
This an issue with UPortal not implementing the specification correctly.  Many
of their classes are implementing HttpSessionBindingListener when they should be
implementing HttpSessionListener.  

See.  http://www.ja-sig.org/issues/browse/UP-1524