You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2000/10/12 02:56:35 UTC
Forcing a new session
I'm deploying Sun's J2EE Pet Store demo on Tomcat. One of the
problems I've run into is that when you log out, it calls invalidate() on
the session, then immediately calls getSession(true) on the request,
expecting a new session to be generated. This blows up in Tomcat (3.2
CVS), since the invalidated session is still in the
RequestImpl.serverSession instance variable, so it gets returned.
I'm not sure whether this is a problem with Tomcat or with the Pet
Store. You can fix it in Tomcat by adding a block like:
try {
serverSession.isNew();
return serverSession;
} catch(IllegalStateException e) {}
to RequestImpl.getSession(), but this is not so nice. Is there
another way to forcibly generate a new session? Or a better patch to
clear out the invalidated one?
Thanks,
Aaron
Re: Forcing a new session
Posted by Paul Frieden <pf...@dchain.com>.
This doesn't look to be related to the cookie problems at all. The
source for the Pet Store actually calls getSession twice in the course
of a single request, so it doesn't ever get to the point of trying to
remove the cookie before it blows up. This is the code from
RequestProcessor:
request.getSession().invalidate();
screenManager = null;
//remove the EJB
scc.remove();
// get new session and put in a new gui controller
HttpSession validSession = request.getSession(true);
It looks like RequestImpl is assuming that if it has a session reference
it is treating it as if it were valid, assuming that it will be verified
elsewhere.
<rant>
As for the cookie problems, I posted a patch several weeks ago that
still applies to 3.2b6 that fixes the problem as far as I can
determine. The whole unified diff is 17 lines long, so its not as if it
were a gigantic patch that can't be properly verified before the
release.
I would love to see a patch that lets the jvmRoute be used on the root
context. I think I have a fix for the cookie deletion behavior, I've
added code that verifies that the correct cookie gets to the correct
context, but none of these seem to have been looked at. I haven't seen
any comments on the later versions of either of these patches. If
anybody wants to see these patches, they've all been posted to the list
at least once.
</rant>
Paul Frieden
"yhs@mimic.onesourcecorp.com" wrote:
>
> On Wed, 11 Oct 2000, Aaron Mulder wrote:
>
> > I'm deploying Sun's J2EE Pet Store demo on Tomcat. One of the
> > problems I've run into is that when you log out, it calls invalidate() on
> > the session, then immediately calls getSession(true) on the request,
> > expecting a new session to be generated. This blows up in Tomcat (3.2
> > CVS), since the invalidated session is still in the
> > RequestImpl.serverSession instance variable, so it gets returned.
> > I'm not sure whether this is a problem with Tomcat or with the Pet
> > Store. You can fix it in Tomcat by adding a block like:
> >
> > try {
> > serverSession.isNew();
> > return serverSession;
> > } catch(IllegalStateException e) {}
> >
> > to RequestImpl.getSession(), but this is not so nice. Is there
> > another way to forcibly generate a new session? Or a better patch to
> > clear out the invalidated one?
> >
> > Thanks,
> > Aaron
> >
>
> i think this is the known bug which has something to do with cookies
> not being able to be deleted/modified. not likely to be fixed in tomcat
> 3.2. it's been there for a loong time.
> -Ys-
> yhs@mimic.onesourcecorp.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Forcing a new session
Posted by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com>.
On Wed, 11 Oct 2000, Aaron Mulder wrote:
> I'm deploying Sun's J2EE Pet Store demo on Tomcat. One of the
> problems I've run into is that when you log out, it calls invalidate() on
> the session, then immediately calls getSession(true) on the request,
> expecting a new session to be generated. This blows up in Tomcat (3.2
> CVS), since the invalidated session is still in the
> RequestImpl.serverSession instance variable, so it gets returned.
> I'm not sure whether this is a problem with Tomcat or with the Pet
> Store. You can fix it in Tomcat by adding a block like:
>
> try {
> serverSession.isNew();
> return serverSession;
> } catch(IllegalStateException e) {}
>
> to RequestImpl.getSession(), but this is not so nice. Is there
> another way to forcibly generate a new session? Or a better patch to
> clear out the invalidated one?
>
> Thanks,
> Aaron
>
i think this is the known bug which has something to do with cookies
not being able to be deleted/modified. not likely to be fixed in tomcat
3.2. it's been there for a loong time.
-Ys-
yhs@mimic.onesourcecorp.com