Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 13123 invoked from network); 24 Nov 2003 23:41:21 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 24 Nov 2003 23:41:21 -0000 Received: (qmail 12672 invoked by uid 500); 24 Nov 2003 23:41:01 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 12480 invoked by uid 500); 24 Nov 2003 23:41:00 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 12461 invoked from network); 24 Nov 2003 23:41:00 -0000 Received: from unknown (HELO mail.wanconcepts.com) (66.127.87.82) by daedalus.apache.org with SMTP; 24 Nov 2003 23:41:00 -0000 Received: from besclient.wanconcepts.com [66.127.87.83] by mail.wanconcepts.com with ESMTP (SMTPD32-8.03) id A5A313D0026; Mon, 24 Nov 2003 15:34:59 -0800 Message-Id: <5.1.0.14.2.20031124145824.00b7e730@mail.wanconcepts.com> X-Sender: bstansberry@mail.wanconcepts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Nov 2003 15:39:49 -0800 To: "Tomcat Developers List" From: Brian Stansberry Subject: Re: 9077 Patch In-Reply-To: <3FC2783D.4020408@apache.org> References: <6A403F1AF18CB544A044D7572E2800CCA4C052@sits2.itssiemens.com> <6A403F1AF18CB544A044D7572E2800CCA4C052@sits2.itssiemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N At 10:29 PM 11/24/2003 +0100, you wrote: >Nelson, Luke wrote: > >>Hopefully Brian can take the patch I added, and test it under 5.0 >>since he indicated he was available to make the change. > >That would be good. I can apply a verified TC 5 patch tomorrow if you can post one. Otherwise, the issue won't be fixed in 5.0.15. Yes, I'm working on this and have integrated Luke's patch w/ the TC5 SSO version. Had to run out and fix a customer's broken network, but I'll be on this the rest of the day. But, the IllegalStateException issue needs to be resolved. Luke, your patch has no problem in TC4 because the IllegalStateException in getLastAccessedTime() was added in TC5. Off the top of my head, I can think of only 1 potential workaround, which is to move the logic that throws the exception to HttpSessionFacade; this complies with the javadoc version that specifies the exception in javax.servlet.http.HttpSession but leaves the method in StandardSession available for internal use anytime. Kind of a hack, and it changes the behavior of the public API of StandardSession. But, the exception throw is not specified in the javadoc for interface o.a.c.Session, and a quick look at the TC5 usages of o.a.c.Session.getLastAccessedTime() shows a few calls to the method that 1) aren't making any obvious tests for session validity before invoking it; and 2) aren't catching IllegalStateException. 1) JDBCStore.save() 2) ManagerBase.getLastAccessedTime() 3) PersistentValve.isSessionStale() Or we can hope the final spec matches the JSR154-PFD3 javadoc, and not the J2EE1.4 docs on the Sun site ;-) Any thoughts? Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel: (510) 894-0114 x 116 Fax: (510) 797-3005 --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org