Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.0-alpha-2
-
Fix Version/s: None
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Environment:Today's CVS version
-
Number of attachments :
Description
sessionDestroyed in ServletContainerListener accesses the session when killing the container. According to the Servlet spec, sessionDestroyed is called after the session is invalidated.
To implement the desired behavior one must use HttpSessionBindingListener:
public void sessionCreated(HttpSessionEvent event) {
HttpSession session = event.getSession();
ServletContext context = session.getServletContext();
ContainerComposer assembler = getAssembler(context);
ObjectReference containerRef = new SessionScopeObjectReference(session, SESSION_CONTAINER);
ObjectReference parentContainerRef = new ApplicationScopeObjectReference(context, APPLICATION_CONTAINER);
ContainerBuilder containerBuilder = new DefaultLifecycleContainerBuilder(assembler);
containerBuilder.buildContainer(containerRef, parentContainerRef, session);
session.setAttribute("SESSION_CONTAINER_HELPER",
new HttpSessionBindingListener {
public void valueBound(HttpSessionBindingEvent event) {
}
public void valueUnbound(HttpSessionBindingEvent event)
{ HttpSession session = event.getSession(); ObjectReference containerRef = new SessionScopeObjectReference(session, SESSION_CONTAINER); killContainer(containerRef); }});
}
public void sessionDestroyed(HttpSessionEvent event) {
}
Even better would be to make SessionScopeObjectReference implement HttpSessionBindingListener.
Activity
Patch attached.
Philipp Meier
added a comment - Patch attached. Philipp Meier
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Attachment | servlet-fix-sessionlistener.diff [ 11331 ] |
Here's a patch upated to go against the latest 1.9 version on ServletContainerListener in CVS. It reformats the existing patch to apply with nicer indentation and a slight change to the key used for the session helper attribute (just to be more clear on what it is for). The patch also includes a change to the name of the context parameter from the generic "assembler" (which would be fine for a scoped servlet param, but not a global context param) to "picoextras-container-composer".
Jake
Jacob Kjome
added a comment - Here's a patch upated to go against the latest 1.9 version on ServletContainerListener in CVS. It reformats the existing patch to apply with nicer indentation and a slight change to the key used for the session helper attribute (just to be more clear on what it is for). The patch also includes a change to the name of the context parameter from the generic "assembler" (which would be fine for a scoped servlet param, but not a global context param) to "picoextras-container-composer".
Jake Jacob Kjome
made changes -
| Attachment | patch.1.9.diff [ 11359 ] |
I see that the patch was applied with a few mods. I'm now wondering whether the information supplied about sessionDestroyed() getting called after the session object has already been destroyed, as originally reported, is true? The reason why I doubt this is that the ServletContext is still available in contextDestroyed() of a ServletContextListener. If the Session behaved as described in the report, then sessionDestroyed() would be totally inconsistent with contextDestroyed().
Look at the doc for sessionDestroyed()...
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/servletapi/javax/servlet/http/HttpSessionListener.html#sessionDestroyed(javax.servlet.http.HttpSessionEvent)
"Notification that a session is about to be invalidated."
That's "about to", not "has been".
And then check this message...
http://www.caucho.com/support/resin-interest/0206/0227.html
He's accessing the session in sessionDestroyed() just fine. It seems to me that the hack of using a session attribute listener can be removed and the old sessionDestroyed() can be added back....or, we can make it not a hack and have the SessionScopeObjectReference implement HttpSessionAttribtueListener.
Jake
Jacob Kjome
added a comment - I see that the patch was applied with a few mods. I'm now wondering whether the information supplied about sessionDestroyed() getting called after the session object has already been destroyed, as originally reported, is true? The reason why I doubt this is that the ServletContext is still available in contextDestroyed() of a ServletContextListener. If the Session behaved as described in the report, then sessionDestroyed() would be totally inconsistent with contextDestroyed().
Look at the doc for sessionDestroyed()...
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/servletapi/javax/servlet/http/HttpSessionListener.html#sessionDestroyed(javax.servlet.http.HttpSessionEvent )
"Notification that a session is about to be invalidated."
That's "about to", not "has been".
And then check this message...
http://www.caucho.com/support/resin-interest/0206/0227.html
He's accessing the session in sessionDestroyed() just fine. It seems to me that the hack of using a session attribute listener can be removed and the old sessionDestroyed() can be added back....or, we can make it not a hack and have the SessionScopeObjectReference implement HttpSessionAttribtueListener.
Jake The behaviour of HttpSessionListener#sessionDestroyed changed form J2EE 1.3 to J2EE 1.4. Version 1.4 says "Notification that a session is about to be invalidated." whereas 1.3 says "Notification that a session was invalidated." I didn't looked in the Servlet Spec but I'm sure for 2.3 it was "was invalidated", too.
So to be on the safe side one should use HttpSessionBindingListener as I proposed.
I know that tomcat and resin implement the "about to be invalidated" behaviour, but in Jetty the session is already invalidated, though a NPE or IllegalStateException will be thrown.
Philipp Meier
added a comment - The behaviour of HttpSessionListener#sessionDestroyed changed form J2EE 1.3 to J2EE 1.4. Version 1.4 says "Notification that a session is about to be invalidated." whereas 1.3 says "Notification that a session was invalidated." I didn't looked in the Servlet Spec but I'm sure for 2.3 it was "was invalidated", too.
So to be on the safe side one should use HttpSessionBindingListener as I proposed.
I know that tomcat and resin implement the "about to be invalidated" behaviour, but in Jetty the session is already invalidated, though a NPE or IllegalStateException will be thrown. I believe this is fixed. Please reopen if it is not the case.
Aslak Hellesøy
added a comment - I believe this is fixed. Please reopen if it is not the case. Aslak Hellesøy
made changes -
| Resolution | Fixed [ 1 ] | |
| Assignee | Aslak Hellesoy [ rinkrank ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
Could you please upload a patch as described here:
http://wiki.codehaus.org/picocontainer/HowToContribute
http://wiki.codehaus.org/picocontainer/UnifiedPatch
Aslak