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]
