Hey Remy,
can you please explain why the remove attribute event notification is wrong when
context is destroy?
Thanks Peter
Remy Maucherat schrieb:
Peter Rossbach wrote:
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?
No, it's not ok, it's wrong ;) This came up recently, and caused problems.
=====
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 :-)
This is also outside the application scope.
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]
