Re: [OT] saving stats from session when session destroyed

[Tamas Szabo <sz...@gmail.com>]

Craig McClanahan wrote:

>On 7/29/05, Varley, Roger <Ro...@atosorigin.com> wrote:
>  
>
>>>I could be losing my mind, but, I swear that I tried this technique
>>>once and by the time the sessionDestroyed() method was called, I was
>>>not able to get any of the session attributes back anymore. For
>>>various reasons, the webapps I develop need to be deployable in a
>>>Servlet 2.3 environment. Is this something where the behavior changed
>>>for the better in Servlet 2.4 versus 2.3?
>>>
>>>      
>>>
>></Lurk>
>>No, you are not loosing your mind. The Servlet 2.3 specification defines HttpSessionListener#SessionDestroyed as "Notification that a session was invalidated". Thus anyone who followed the specification to the letter, as many container authors did, ended up with a method that was somewhat less than useful. In the 2.4 specification, the wording was changed to "Notification that a session is about to be invalidated".
>>
>>    
>>
>
>One approach to consider is to make your listener implement
>HttpSessionAttributeListener as well as HttpSessionListener.  That
>means you'll hear about session attributes being removed -- which is
>what happens as the session is being invalidated or timed out.  All of
>these calls will happen before the sessionDestroyed() notification.
>
>  
>

But how would you know that the attribute was removed because 
sessionDestroyed will be called or
because some code in the application removed the attribute for some reason?

Tamas


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] saving stats from session when session destroyed

[Tamas Szabo <sz...@gmail.com>]

Craig McClanahan wrote:

>On 7/31/05, Tamas Szabo <sz...@gmail.com> wrote:
>  
>
>>Craig McClanahan wrote:
>>    
>>
>>>One approach to consider is to make your listener implement
>>>HttpSessionAttributeListener as well as HttpSessionListener.  That
>>>means you'll hear about session attributes being removed -- which is
>>>what happens as the session is being invalidated or timed out.  All of
>>>these calls will happen before the sessionDestroyed() notification.
>>>      
>>>
>>But how would you know that the attribute was removed because
>>sessionDestroyed will be called or
>>because some code in the application removed the attribute for some reason?
>>    
>>
>
>There is no "one size fits all" answer to this question.
>
This is exactly what I meant.

Having a sessionDestroyed that has no access to the attributes is 
unusable in the majority of the cases.
I don't really know what is the process of making the specs available to 
the public, but isn't
there a way to make corrections of mistakes that are found later?

I mean that if they changed the specs in 2.4, they probably realized 
that there was a mistake in 2.3.
But if they didn't correct the error in 2.3 they make things harder for 
the users of the API.

Now it is probably impossible or complicates things a lot if you want to 
make some utility code
which should be general and thus usuable with the 2.4, 2.3, .. Servlet APIs.


>  A couple alternative approaches:
>
>* Make sure that there is no "some reason" to remove this attribute
>  *unless* you are terminating the session, or it is timing out.  That
>  way, the meaning of this attribute being removed would be unambiguous.
>  (You could even have a special attribute reserved for this purpose,
>  although you are not going to have any guarantees on the order in
>  which the attributes are being removed.)
>
>* Prior to calling session.invalidate(), set a flagging attribute of some
>  sort that notifies your listener "I am about to invalidate this session.
>  This won't get done on session timeouts, though.
>  
>
Your approaches might be usuable but in special cases only. To be more 
correct you have to make
the code that handles attributes special or it won't work.

Tamas


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] saving stats from session when session destroyed

[Craig McClanahan <cr...@gmail.com>]

On 7/31/05, Tamas Szabo <sz...@gmail.com> wrote:
> Craig McClanahan wrote:
> >One approach to consider is to make your listener implement
> >HttpSessionAttributeListener as well as HttpSessionListener.  That
> >means you'll hear about session attributes being removed -- which is
> >what happens as the session is being invalidated or timed out.  All of
> >these calls will happen before the sessionDestroyed() notification.
> 
> But how would you know that the attribute was removed because
> sessionDestroyed will be called or
> because some code in the application removed the attribute for some reason?

There is no "one size fits all" answer to this question.  A couple
alternative approaches:

* Make sure that there is no "some reason" to remove this attribute
  *unless* you are terminating the session, or it is timing out.  That
  way, the meaning of this attribute being removed would be unambiguous.
  (You could even have a special attribute reserved for this purpose,
  although you are not going to have any guarantees on the order in
  which the attributes are being removed.)

* Prior to calling session.invalidate(), set a flagging attribute of some
  sort that notifies your listener "I am about to invalidate this session.
  This won't get done on session timeouts, though.

> 
> Tamas
> 

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org