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 IllegalStateExceptionsThe 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
