Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
From: "deacon Marcus" <deacon_marcus@wwtech.pl>
To: "'Tomcat Developers List'" <tomcat-dev@jakarta.apache.org>
Subject: RE: Sessions - bug in Tomcat 4.1.24
Date: Thu, 12 Jun 2003 11:37:45 +0200
Organization: Quinotaur.org
Message-ID: <000001c330c6$47c07940$496a793e@nb1>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <017201c33077$eae20bb0$ec66a8c0@bbarkerxp>
Importance: Normal

Hello,

> -----Original Message-----
> From: Bill Barker [mailto:wbarker@wilshire.com] 
> Sent: Thursday, June 12, 2003 2:17 AM
> To: Tomcat Developers List
> Subject: Re: Sessions - bug in Tomcat 4.1.24
> 
> 
> 
> ----- Original Message ----- 
> From: "deacon Marcus" <deacon_marcus@wwtech.pl>
> To: <tomcat-dev@jakarta.apache.org>
> Sent: Wednesday, June 11, 2003 4:13 PM
> Subject: Sessions - bug in Tomcat 4.1.24
> 
> 
> > Hello,
> > It seems in Tomcat 4.1.24 HttpSession is already invalid 
> when passed 
> > to HttpSessionListener.sessionDestroyed(), which just does not make 
> > sense. API Docs say: "public void sessionDestroyed(HttpSessionEvent 
> > se) Notification that a session is about to be invalidated.", in my 
> > opinion "about to be" means that the Session should be 
> valid when this 
> > method is called until it returns.
> 
> In my copy of the 2.3 Servlet Spec, section 15.1.14.1 says:
>     "Notification that a session was invalidated."
> I read that as saying that Tomcat's behavior is corrent.

In http://java.sun.com/j2ee/sdk_1.3/techdocs/api/ :
sessionDestroyed(HttpSessionEvent se) 
          Notification that a session was invalidated.

In http://java.sun.com/j2ee/1.4/docs/api/
sessionDestroyed(HttpSessionEvent se) 
          Notification that a session is about to be invalidated.

I'd say it is correct, according to flawed specification :/ - all other
types of listeners are notified after the object in question has become
active, and before it has become dead. Otherwise the whole notification
thing is just useless. Right now, I must have access to Session's
attributes just before it's destruction, and the _only_ method that
works at sessionDestroyed is getId. What I'm supposed to do, according
do the specs? Bind a HashMap to ServletContext with Session's Id as the
key so I have some way to get Session's "pseudo-attributes" past its
death? Sounds crazy, but that's the sanest thing possible now without
modifying Tomcat's code in "my" copies :/ , and that's exactly what I'd
like to avoid - there's always some smartass who tries to upgrade
modified versions no matter how many times told not to do so and then
all hell brakes loose.

But - Tomcat 5.0 seems to follow EE 1.4 ( = Servlets 2.4) no matter what
Servlets version, 2.3 or 2.4, current WebApp expects?

[...]

Greetings, deacon Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org