Re: Question: Strange Session Remove Attribute
Hmm, but I can't find a statement that the valueUnbound get an invalid session, when it called after sessionDestoryed. HttpSessionBindingListener === /** * * Notifies the object that it is being unbound * from a session and identifies the session. * * @param eventthe event that identifies *the session * * @see #valueBound * */ public void valueUnbound(HttpSessionBindingEvent event); I thing the part identifies the session is in conflict with the current tomcat implementation. Today the user get a IllegalStateException at event.getSession().getId() instead the session identifier. The current servlet spec is not clear at this session event definition. :( What is correct? - current handling - emit remove session event and after this the session is invalid - remove emit event after invalidation What we can do? - document the situation Add lifecycle diagrams ( state flow) -propose a change to the spec team Don't emit remove session attribute events, when session destoryed, like ServletContext and ServletRequest handling ( my favorit) Only direct removeAttribute calls, emit remove event. Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hups, the remove session attribute events after session destory is documented at the servlet spec? Any hint welcome Yes, read the javadoc for HttpSessionBindingListener. 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]
Re: Question: Strange Session Remove Attribute
Peter Rossbach wrote: Hmm, but I can't find a statement that the valueUnbound get an invalid session, when it called after sessionDestoryed. HttpSessionBindingListener === /** * * Notifies the object that it is being unbound * from a session and identifies the session. * * @param eventthe event that identifies *the session * * @see #valueBound * */ public void valueUnbound(HttpSessionBindingEvent event); I thing the part identifies the session is in conflict with the current tomcat implementation. Interface HttpSessionBindingListener: Causes an object to be notified when it is bound to or unbound from a session. The object is notified by an HttpSessionBindingEvent object. This may be as a result of a servlet programmer explicitly unbinding an attribute from a session, due to a session being invalidated, or due to a session timing out. Today the user get a IllegalStateException at event.getSession().getId() instead the session identifier. The current servlet spec is not clear at this session event definition. :( What is correct? - current handling - emit remove session event and after this the session is invalid - remove emit event after invalidation What we can do? - document the situation Add lifecycle diagrams ( state flow) -propose a change to the spec team Don't emit remove session attribute events, when session destoryed, like ServletContext and ServletRequest handling ( my favorit) Only direct removeAttribute calls, emit remove event. I give up ;) Yes, the current behavior is certain to be the correct one. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question: Strange Session Remove Attribute
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question: Strange Session Remove Attribute
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]
Re: Question: Strange Session Remove Attribute
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]
Re: Question: Strange Session Remove Attribute
Peter Rossbach wrote: Hey Remy, can you please explain why the remove attribute event notification is wrong when context is destroy? Because you're not actually removing them, you're just cleaning up objects. Did you notice you don't get notifications on start, etc ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question: Strange Session Remove Attribute
Good answer! But why we emit remove session attribute events when sesssion is destroy? I think the session expire is also a clean up thing and nobody need the remove attribute events. Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hey Remy, can you please explain why the remove attribute event notification is wrong when context is destroy? Because you're not actually removing them, you're just cleaning up objects. Did you notice you don't get notifications on start, etc ? 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]
Re: Question: Strange Session Remove Attribute
Peter Rossbach wrote: Good answer! But why we emit remove session attribute events when sesssion is destroy? I think the session expire is also a clean up thing and nobody need the remove attribute events. Because the stupid wording which explicitely mandates the nonsense for sessions isn't present for context attributes ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question: Strange Session Remove Attribute
Hups, the remove session attribute events after session destory is documented at the servlet spec? Any hint welcome Peter Remy Maucherat schrieb: Peter Rossbach wrote: Good answer! But why we emit remove session attribute events when sesssion is destroy? I think the session expire is also a clean up thing and nobody need the remove attribute events. Because the stupid wording which explicitely mandates the nonsense for sessions isn't present for context attributes ;) 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]
Re: Question: Strange Session Remove Attribute
Peter Rossbach wrote: Hups, the remove session attribute events after session destory is documented at the servlet spec? Any hint welcome Yes, read the javadoc for HttpSessionBindingListener. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question: Strange Session Remove Attribute
- Original Message - From: Peter Rossbach [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Sunday, April 03, 2005 5:04 AM Subject: Question: Strange Session Remove Attribute 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 ;-). 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). regards Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question: Strange Session Remove Attribute
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]
