tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Frieden <pfrie...@dchain.com>
Subject Re: Forcing a new session
Date Thu, 12 Oct 2000 20:49:48 GMT
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

Mime
View raw message