Craig McClanahan wrote:

On 7/31/05, Tamas Szabo <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to