PicoContainer
  1. PicoContainer
  2. PICO-75

Improper pico shutdown in servlet environment

          Details

          • Type: Bug Bug
          • Status: Closed Closed
          • Priority: Major Major
          • Resolution: Duplicate
          • Affects Version/s: 1.0-beta-5
          • Fix Version/s: None
          • Component/s: PicoContainer (Java)
          • Labels:
            None
          • Environment:
            Using Pico 1.0-SNAPSHOT, Pico extras 1.0-alpha-1-SNAPSHOT, WebWork 2.0-beta2 and XWork 1.0-beta2, Tomcat 4.1.29
          • Number of attachments :
            0

            Description

            When using Pico container in a WW2 web application, the following exception is thrown when the servlet container shuts down (see below for a description of web.xml):

            Session event listener threw exception
            java.lang.RuntimeException: Cannot shutdown container
            at org.picoextras.integrationkit.DefaultLifecycleContainerBuilder.killContainer(DefaultLifecycleContainerBuilder.java:57)
            at org.picoextras.servlet.ServletContainerListener.sessionDestroyed(ServletContainerListener.java:74)
            at org.apache.catalina.session.StandardSession.expire(StandardSession.java:659)
            at org.apache.catalina.session.StandardSession.expire(StandardSession.java:608)
            at org.apache.catalina.session.StandardManager.processExpires(StandardManager.java:793)
            at org.apache.catalina.session.StandardManager.run(StandardManager.java:870)
            at java.lang.Thread.run(Thread.java:534)
            Caused by: java.lang.IllegalStateException: getAttribute: Session already invalidated
            at org.apache.catalina.session.StandardSession.getAttribute(StandardSession.java:954)
            at org.apache.catalina.session.StandardSessionFacade.getAttribute(StandardSessionFacade.java:171)
            at org.picoextras.servlet.SessionScopeObjectReference.get(SessionScopeObjectReference.java:36)
            at org.picoextras.integrationkit.DefaultLifecycleContainerBuilder.killContainer(DefaultLifecycleContainerBuilder.java:46)
            ... 6 more

            --------

            Extract from WW2/Pico environment setup (web.xml):

            <context-param>
            <param-name>assembler</param-name>
            <param-value>mypackage.MyContainerAssembler</param-value>
            </context-param>

            <!-- PicoContainer Hook -->
            <listener>
            <listener-class>
            org.picoextras.webwork2.WebWork2ContainerListener
            </listener-class>
            </listener>

            <servlet>
            <servlet-name>webwork</servlet-name>
            <!-- PicoContainer enabled dispatcher -->
            <servlet-class>
            org.picoextras.webwork2.PicoServletDispatcher
            </servlet-class>
            </servlet>

              Issue Links

              depends upon

              Bug - A problem which impairs or prevents the functions of the product. PICO-74 NPE in PicoActionInvocation

              • Major - Major loss of function.
              • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
              is depended upon by

              Improvement - An improvement or enhancement to an existing feature or task. PICO-81 ContainerAssembler scope parameter as Object

              • Major - Major loss of function.
              • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

                Activity

                Hide
                Permalink
                Vincent Tence added a comment -

                To reproduce this issue, PICO-74 needs to be resolved.

                Here's a quick hack to get through PICO-74 and get this error:

                public class PicoActionInvocation extends DefaultActionInvocation implements KeyConstants {

                <snip/>

                /**

                • Copied and adapted from DefaultActionInvocation.createContextMap().
                  */
                  private OgnlValueStack getStackSafely() {
                  OgnlValueStack stack = getStack();
                  if (stack != null) return stack;

                if ((extraContext != null) && (extraContext.containsKey(ActionContext.VALUE_STACK))) {
                stack = (OgnlValueStack) extraContext.get(ActionContext.VALUE_STACK);

                if (stack == null)

                { throw new IllegalStateException("There was a null Stack set into the extra params."); }

                } else

                { // create the value stack // this also adds the ValueStack to its context stack = new OgnlValueStack(); }

                // put extraContext in
                if (extraContext != null)

                { stack.getContext().putAll(extraContext); }

                return stack;
                }

                private MutablePicoContainer getParentContainer()

                { HttpServletRequest request = (HttpServletRequest) getStackSafely().getContext().get(WebWorkStatics.HTTP_REQUEST); ObjectReference ref = new RequestScopeObjectReference(request, REQUEST_CONTAINER); return (MutablePicoContainer) ref.get(); }

                }

                Show
                Vincent Tence added a comment - To reproduce this issue, PICO-74 needs to be resolved. Here's a quick hack to get through PICO-74 and get this error: public class PicoActionInvocation extends DefaultActionInvocation implements KeyConstants { <snip/> /** Copied and adapted from DefaultActionInvocation.createContextMap(). */ private OgnlValueStack getStackSafely() { OgnlValueStack stack = getStack(); if (stack != null) return stack; if ((extraContext != null) && (extraContext.containsKey(ActionContext.VALUE_STACK))) { stack = (OgnlValueStack) extraContext.get(ActionContext.VALUE_STACK); if (stack == null) { throw new IllegalStateException("There was a null Stack set into the extra params."); } } else { // create the value stack // this also adds the ValueStack to its context stack = new OgnlValueStack(); } // put extraContext in if (extraContext != null) { stack.getContext().putAll(extraContext); } return stack; } private MutablePicoContainer getParentContainer() { HttpServletRequest request = (HttpServletRequest) getStackSafely().getContext().get(WebWorkStatics.HTTP_REQUEST); ObjectReference ref = new RequestScopeObjectReference(request, REQUEST_CONTAINER); return (MutablePicoContainer) ref.get(); } }
                Aslak Hellesøy made changes -
                Field Original Value New Value
                Link This issue depends upon PICO-74 [ PICO-74 ]
                Aslak Hellesøy made changes -
                Assignee Joe Walnes [ jwalnes1 ]
                Hide
                Permalink
                Aslak Hellesøy added a comment -

                I'm a bit confused about what you want us to do about this issue.

                Note that I have closed PICO-74 as "Won't Fix".

                1) Is it so that the resolution of http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-147 will make the problem you describe go away?

                Can we close this issue as "Won't Fix" too? (Assuming that it's WW2 that needs to be fixed).

                Show
                Aslak Hellesøy added a comment - I'm a bit confused about what you want us to do about this issue. Note that I have closed PICO-74 as "Won't Fix". 1) Is it so that the resolution of http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-147 will make the problem you describe go away? Can we close this issue as "Won't Fix" too? (Assuming that it's WW2 that needs to be fixed).
                Hide
                Permalink
                Mathias Bogaert added a comment -

                Aslak, this certainly isn't a WW2 or XWork issue.

                The problem here is with the picoextras' servlet module that calls a getAttribute on the HttpSession while it has already been invalidated (from http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpSessionListener.html sessionDestroyed method). Some containers (such as Tomcat) throw an IllegalStateException, other's don't.

                The solution is to wrap have the session bound picocontainer with http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpSessionBindingListener.html, which will then be called when the session is invalidated (and then can stop and dispose the container correctly). I'll try to fix this one and supply a patch.

                Show
                Mathias Bogaert added a comment - Aslak, this certainly isn't a WW2 or XWork issue. The problem here is with the picoextras' servlet module that calls a getAttribute on the HttpSession while it has already been invalidated (from http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpSessionListener.html sessionDestroyed method). Some containers (such as Tomcat) throw an IllegalStateException, other's don't. The solution is to wrap have the session bound picocontainer with http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpSessionBindingListener.html , which will then be called when the session is invalidated (and then can stop and dispose the container correctly). I'll try to fix this one and supply a patch.
                Aslak Hellesøy made changes -
                Link This issue is depended upon by PICO-81 [ PICO-81 ]
                Hide
                Permalink
                Aslak Hellesøy added a comment -

                This is now superceded by PICO-81.

                Also see: http://lists.codehaus.org/pipermail/picocontainer-dev/2003-December/001897.html

                (For the future, please leave issue-related comments in the JIRA issues themselves, otherwise they risk to be overlooked when someone tries to fix the bug).

                Show
                Aslak Hellesøy added a comment - This is now superceded by PICO-81 . Also see: http://lists.codehaus.org/pipermail/picocontainer-dev/2003-December/001897.html (For the future, please leave issue-related comments in the JIRA issues themselves, otherwise they risk to be overlooked when someone tries to fix the bug).
                Aslak Hellesøy made changes -
                Status Open [ 1 ] Closed [ 6 ]
                Resolution Duplicate [ 3 ]
                Assignee Joe Walnes [ jwalnes1 ] Aslak Hellesoy [ rinkrank ]

                  People

                  • Assignee:
                    Aslak Hellesøy
                    Reporter:
                    Vincent Tence
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: