tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach ...@objektpark.de>
Subject Re: Question: Strange Session Remove Attribute
Date Mon, 04 Apr 2005 08:47:44 GMT
Hmm,

I see the following problem with the current session expire strategie.

Today
    a) Notify session destroy event
          => All session attributes are active
    b) Set session as invalid
    c) Notify session remove attribute event - Hups
         => Now the listener detect IllegalStateExceptions

The session attribute listener in normal mode can access the session and 
this is very usefull
to monitoring the app behaviour. At expire session the listener have no 
chance to detect the
invalidation mode.

Now I see to chance to make better support for this case:
1)  add HttpSession.isValid() method
    => Very fine then also other code filter, and jsp can detect the 
Session invalidation.
2)  Add event methods to HttpSessionListener
    public void sessionDestroyed ( HttpSessionEvent se );
    public void sessionAfterDestroyed ( HttpSessionEvent se );
=> Second method emit after all attribute remove from session and now 
session is invalid ;-(

I vote for the first case, but this means wait for Servlet API 2.5.


============

Another problem I detect is at StandardContext listener event notification
    At listenerStop (L 3721)
       we remove the ApplicationEvent Listeners
<<
       setApplicationEventListeners(null);
       setApplicationLifecycleListeners(null);
 >>

     but we need the Listener at
       StandardContext#clearAttributes => 
ApplicationContext#removeAttribute L695

=> Currently we don't emit removeAttribute Events when Context. stop.

Simple fix integrate clearAttributes at listenerStop before remove 
listeners.
OK?

=====

Other thing is: that we don't emit remove request attribute events after 
ServletRequestListener was notify with requestDestory.
I can find this handling at org.apache.catalina.connector.Request.recycle
     At L 391 we clear the attributes, but don't notify the request 
attribute listener.
Is this behaviour spec conform?
What is with request attributes that exist before or after request 
wrapper is active ( s. StandardContextValve#invoke)?
Must we have extra map for real application request attributes and 
another one for container side request attributes ?
   Sounds really strange :-)

Regards
Peter


Remy Maucherat schrieb:

> Bill Barker wrote:
>
>>> Hey
>>>
>>> I have review the getIdInteral changes. At expire (StandardSession, 
>>> DeltaSession) we send first the "SessionDestory events" and after 
>>> this the "Remove Session Attribute" events. Before we send the 
>>> remove attribute events the session set to invalid. Hmm: Why we do 
>>> that? I have read the spec 2.4 but I can find a hint. With this 
>>> handling nobody can access the getId without IllegalStateException 
>>> in a HttpSessionBindingListener or HttpSessionAttributeListener! 
>>> That I can't find this very nice?
>>
>>
>> What can I say, we needed to generate more BZ reports to mark as 
>> INVALID ;-).
>
>
> The tester actually has example code of using getId in a 
> HttpSessionAttributeListener to get an ISE.
>
>>> Can anyone explain this session event handling?
>>
>>
>> There was just a long discussion of this.  For the details, check the 
>> list archives.  The short version is that it's mandated by section 
>> 15.1.7 + Errata 
>> (http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/154errata.txt). 
>
>
>
> (maybe I shouldn't have mentioned it, as Jan didn't appear to have 
> noticed it before: I may have started the trouble ...)
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>


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


Mime
View raw message