[weld-issues] [JBoss JIRA] (CDITCK-482) SessionContextListenerShutdownTest relies on non-specified behaviour
Title: Message Title Tomas Remes commented on CDITCK-482 Re: SessionContextListenerShutdownTest relies on non-specified behaviour Looking at javax.servlet.http.HttpSession there's following statement: When container migrates a session between VMs in a distributed container setting, all session attributes implementing the HttpSessionActivationListener interface are notified. So I would say there should be the check for javax.servlet.http.HttpSessionActivationListener#sessionWillPassivate at first in the case of serialization. We can probably raise Servlet spec clarification issue. Anyway looking at 11.2.1 Event Types and Listener Interfaces in the servlet spec I think adding invalidate call is legal solution. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-482) SessionContextListenerShutdownTest relies on non-specified behaviour
Title: Message Title Mark Struberg commented on CDITCK-482 Re: SessionContextListenerShutdownTest relies on non-specified behaviour ApplicationShutdownLifecycleTest is also affected. What if we set distributablefalse in the web.xml? Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-482) SessionContextListenerShutdownTest relies on non-specified behaviour
Title: Message Title Mark Struberg commented on CDITCK-482 Re: SessionContextListenerShutdownTest relies on non-specified behaviour As pointed out by ~mkouba setting distributable wont help much. See servlet-3.0 spec 10.8 A server should be able to replace an application with a new version without restarting the container. When an application is replaced, the container should provide a robust method for preserving session data within that application. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-482) SessionContextListenerShutdownTest relies on non-specified behaviour
Title: Message Title Tomas Remes commented on CDITCK-482 Re: SessionContextListenerShutdownTest relies on non-specified behaviour I tend to agree. I think it's at least disputable. Servlet spec is bit vague and I can see only: When an application is replaced, the container should provide a robust method for preserving session data within that application. I suggest to add to InitServlet: request.getSession().invalidate(); WDYT? Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-482) SessionContextListenerShutdownTest relies on non-specified behaviour
Title: Message Title Tomas Remes resolved as Done Fixed by adding session.invalidate() call. CDI TCK / CDITCK-482 SessionContextListenerShutdownTest relies on non-specified behaviour Change By: Tomas Remes Status: Open Resolved Fix Version/s: 1.2.5.Final Fix Version/s: 2.0.0.Alpha3 Resolution: Done Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[weld-issues] [JBoss JIRA] (CDITCK-482) SessionContextListenerShutdownTest relies on non-specified behaviour
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-482 SessionContextListenerShutdownTest relies on non-specified behaviour Issue Type: Feature Request Affects Versions: 1.2.4.Final Assignee: Tomas Remes Created: 16/May/15 1:58 PM Priority: Major Reporter: Mark Struberg SessionContextListenerShutdownTest relies on sessionDestroyed getting invoked on undeploy. But this is actually not defined by the servlet spec. Many containers really don't call this. Instead they serialize away the Session to disc or to another cluster node and then de-serialize them back again. In which case the Session continues as nothing has happened. Add Comment
