You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ralph Einfeldt <ra...@uptime-isc.de> on 2003/01/08 13:34:42 UTC
Problem with invalidating a session
I have following little jsp:
<html><head><title></title></head><body>
<%
// Stripped down to the bare minimum. In the real life
// this is intended to happen only on specific conditions
session.invalidate();
session = request.getSession(true);
// Now there is a new session
session.putValue("Test", "Test");
%><jsp:useBean
id="testbean"
class="java.lang.String"
scope="session"
/>
Some Content (Only reached with Scope != session)
</body></html>
The useBean with scope session fails as the pageContext
holds a reference to the invalidated session.
That causes tomcat to throw a IllegalStateException:
getAttribute: Session already invalidated
Although I quite understand why this happens, I couldn't find
in the 1.2 Spec anything that denies this kind of usage.
Is the spec just not precise enough or am I to blind to see it ?
Has anybody a solution to work around this problem beside using
a response.redirect() directly after invalidating the session?
BTW: Please don't shout 'Do not use scriptlets in jsps', the
code has to run in a jsp engine that doesn't support taglibs
and filters.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem with invalidating a session
Posted by Tim Funk <fu...@joedog.org>.
From the Servlet 2.3 Spec. (Some info snipped for brevity)
HttpSerlvetRequest.getSession(boolean)
Returns the current HttpSession associated with this request or, if if
there is no current session and create is true, returns a new session.
Parameters:
<code>true</code> - to create a new session for this request if
necessary; false to return null if there’s no current session
Returns: the HttpSession associated with this request or null if create
is false and the request has no valid session
HttpSession.setAttribute(String, Object)
Throws: IllegalStateException - if this method is called on an
invalidated session
--------
Your code invalidates the session. getSession(true) is returning a
reference to session you just the invalidated. There is no way to
retrieve a "new" session. This behavior is correct for
getSession(boolean) since a HttpSession is already been bound to the
request. Since you invalidated it, the session becomes worthless. At
that point, issuing a sendRedirect needs to be done to issue a new
browser request to obtain a new session.
My main point is getSession(true) must return a HttpSession. There is
nothing in the spec that states if a session becomes invalidated during
the life of a request, that getSession(true) must return a new session.
-Tim
Ralph Einfeldt wrote:
> I have following little jsp:
>
> <html><head><title></title></head><body>
> <%
>
> // Stripped down to the bare minimum. In the real life
> // this is intended to happen only on specific conditions
> session.invalidate();
> session = request.getSession(true);
>
> // Now there is a new session
> session.putValue("Test", "Test");
>
> %><jsp:useBean
> id="testbean"
> class="java.lang.String"
> scope="session"
> />
> Some Content (Only reached with Scope != session)
> </body></html>
>
> The useBean with scope session fails as the pageContext
> holds a reference to the invalidated session.
> That causes tomcat to throw a IllegalStateException:
> getAttribute: Session already invalidated
>
> Although I quite understand why this happens, I couldn't find
> in the 1.2 Spec anything that denies this kind of usage.
>
> Is the spec just not precise enough or am I to blind to see it ?
>
> Has anybody a solution to work around this problem beside using
> a response.redirect() directly after invalidating the session?
>
> BTW: Please don't shout 'Do not use scriptlets in jsps', the
> code has to run in a jsp engine that doesn't support taglibs
> and filters.
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>