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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to