[#CACHE-229] Tomcat 5.5.12 throws IllegalStateException on getId() / fixed Servlet Spec 2.4

OSCache

Tomcat 5.5.12 throws IllegalStateException on getId() / fixed Servlet Spec 2.4

Created: 21/Dec/05 12:02 PM Updated: 12/Feb/06 06:49 AM

Component/s:

None

Affects Version/s:

2.2 final

Fix Version/s:

2.3

Flags:

Important

Description

« Hide

Obviously the Session.getId() has to throw an IllegalStateException after the session has been validated according to the Spec 2.4:
http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/154errata.txt

Tomcat does behave like this in the latest version 5.5.12. There also a Tomcat issue but obviously it won't be fixed:
http://issues.apache.org/bugzilla/show_bug.cgi?id=36994

I think OSCache has to deal with this since this will trigger exceptions like:
java.lang.IllegalStateException: getId: Session already invalidated
        at org.apache.catalina.session.StandardSession.getId(StandardSession.java:328)
        at org.apache.catalina.session.StandardSessionFacade.getId(StandardSessionFacade.java:78)
        at com.opensymphony.oscache.web.ServletCache.valueUnbound(ServletCache.java:96)
        at org.apache.catalina.session.StandardSession.removeAttributeInternal(StandardSession.java:1607)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:737)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:643)
        at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1088)
        at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:149)

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Lars Torunski - [22/Dec/05 12:40 AM ]

Workaround for releases until 2.2: use at least warn log level

In release 2.3 we won't access the session's id by invoking HttpSessionBindingEvent event.getSession().getId()

The final Servlet Spec. 2.4 doesn't document that getId() will throw an IllegalStateException when the session is invalidated. This may change with the Servlet Spec. 2.5, so we change the OSCache behaviour.

Taken from Java™ Servlet Specification Version 2.4, page 267:
getId()
    public java.lang.String getId()
        Returns a string containing the unique identifier assigned to this session. The
        identifier is assigned by the servlet container and is implementation dependent.
        Returns: a string specifying the identifier assigned to this session

[ Permlink | « Hide ]

Lars Torunski - [22/Dec/05 03:44 AM ]

The current jsr154 maintenance release 3 contains a change in the getId() method of the HttpSession class, page 273:

getId()
    public java.lang.String getId()
        Returns a string containing the unique identifier assigned to this session. The
        identifier is assigned by the servlet container and is implementation dependent.

Returns: a string specifying the identifier assigned to this session

Throws:
            IllegalStateException - if this method is called on an invalidated session

http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/index3.html
http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/servlet-2_5-changelog.html

[ Permlink | « Hide ]

Christian Seiler - [22/Dec/05 04:21 AM ]

I think that even spec. 2.4 is affected. There was just a typo in the original specification which was fixed by the errate document I mentioned above. here another link that makes mor eobvious that the errata file belongs to spec 2.4:

http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/JSR154ChangeLog.html
Search for "Fix typos in HttpSession"

And I really want to emphasize the severity of this issue: Calling session.invalidate() simply does not work with Tomcat 5.5.12 and OSCache2.2.
The Tomcat guys won't change catalina as it is compliant to the specs (I have currently patched Tomcat, but that is not a good thing of course)

I would think about backporting this independence from calling getId() feature to OSCache 2.2.x

[ Permlink | « Hide ]

Lars Torunski - [22/Dec/05 11:05 AM ]

Christian, for a workaround you should use warn level for OSCache in release 2.2 or you can use the current CVS HEAD of OSCache.