Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 42023 invoked from network); 12 Oct 2000 00:57:14 -0000 Received: from upright.cs.princeton.edu (root@128.112.136.7) by locus.apache.org with SMTP; 12 Oct 2000 00:57:14 -0000 Received: from gentoo.CS.Princeton.EDU (IDENT:root@gentoo [128.112.169.41]) by upright.CS.Princeton.EDU (8.10.2/8.10.2) with ESMTP id e9C0uaU26128 for ; Wed, 11 Oct 2000 20:56:36 -0400 (EDT) Received: from localhost by gentoo.CS.Princeton.EDU (8.9.3) id UAA13269; Wed, 11 Oct 2000 20:56:35 -0400 Date: Wed, 11 Oct 2000 20:56:35 -0400 (EDT) From: Aaron Mulder X-Sender: ammulder@gentoo.CS.Princeton.EDU To: Tomcat Dev List Subject: Forcing a new session Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N 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