Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.2
    • Fix Version/s: 3.1.0.Tracking
    • Component/s: None
    • Labels:
      None
    • Environment:

      JBoss 6.1.0-SNAPSHOT (Hudson build) with updated Weld 1.1.1-Final and updated Mojarra 2.1.2

      Description

      s:viewAction will not invoke after updating to Mojarra 2.1.2.

      Tested with:

      <f:metadata>
      <s:viewAction action="#

      {myBean.validate}

      "/>
      </f:metadata>

        Gliffy Diagrams

          Activity

          Hide
          ssachtleben Sebastian Sachtleben added a comment -

          Mojarra 2.0.3 ( b05) works fine the method will be invoked. But after updating the breakpoint will not hit and it will not invoke at all...

          Show
          ssachtleben Sebastian Sachtleben added a comment - Mojarra 2.0.3 ( b05) works fine the method will be invoked. But after updating the breakpoint will not hit and it will not invoke at all...
          Hide
          bleathem Brian Leathem added a comment - - edited

          I've written some JSFUnit/Arquillian tests for the viewAction, currently targeting JBoss AS6 as a baseline.
          There are two tests (available in faces/fetaure/jsfunit_arquillian branch):

              // testing the viewAction loading data into a property
              @Test
              @InitialPage("/load_data.xhtml")
              public void checkDataLoad(JSFServerSession server,
          JSFClientSession client) throws IOException {
                  Assert.assertEquals("/load_data.xhtml", server.getCurrentViewID());
                  Assert.assertTrue(client.getPageAsText().contains("Data Loaded"));
              }
          

              // testing viewAction navigation
              @Test
              @InitialPage("/goto_result.xhtml")
              public void checkNavigation(JSFServerSession server,
          JSFClientSession client) throws IOException {
                  Assert.assertEquals("/result.xhtml", server.getCurrentViewID());
                  Assert.assertTrue(client.getPageAsText().contains("Result page"));
              }
          

          The first test works, but the second one fails with the server.log stacktrace:

          2011-07-12 09:23:20,116 DEBUG [org.jboss.seam.faces.event.PhaseEventBridge] (http-localhost%2F127.0.0.1-8080-2) Fired event [javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl@46ffcd87]] with qualifiers [[Ljava.lang.annotation.Annotation;@38b9d37b]
          2011-07-12 09:23:20,117 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/a6c419-34e7-45b1-bc37-e751a70a57c6].[FacesServlet]] (http-localhost%2F127.0.0.1-8080-2) Servlet.service() for servlet FacesServlet threw exception: java.lang.IllegalStateException: Context is already active
                  at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:301) [:6.0.0.Final]
                  at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:110) [:6.0.0.Final]
                  at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:84) [:6.0.0.Final]
                  at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:224) [:2.0.3-]
                  at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:95) [:2.0.3-]
                  at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107) [:2.0.3-]
                  at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114) [:2.0.3-]
                  at org.jboss.seam.faces.component.UIViewAction.broadcast(UIViewAction.java:405) [:]
                  at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:781) [:2.0.3-]
                  at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1246) [:2.0.3-]
                  at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:77) [:2.0.3-]
                  at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97) [:2.0.3-]
                  at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114) [:2.0.3-]
                  at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308) [:2.0.3-]
                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [:6.0.0.Final]
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
                  at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67) [:6.0.0.Final]
                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [:6.0.0.Final]
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
                  at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [:6.0.0.Final]
                  at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.Final]
                  at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final]
                  at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final]
                  at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final]
                  at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final]
                  at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final]
                  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final]
                  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final]
                  at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final]
                  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final]
                  at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final]
                  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final]
                  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.Final]
                  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [:6.0.0.Final]
                  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final]
                  at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
          

          I verified this failure with a manually created example app (available in faces/examples on the develop branch).

          Show
          bleathem Brian Leathem added a comment - - edited I've written some JSFUnit/Arquillian tests for the viewAction, currently targeting JBoss AS6 as a baseline. There are two tests (available in faces/fetaure/jsfunit_arquillian branch): // testing the viewAction loading data into a property @Test @InitialPage("/load_data.xhtml") public void checkDataLoad(JSFServerSession server, JSFClientSession client) throws IOException { Assert.assertEquals("/load_data.xhtml", server.getCurrentViewID()); Assert.assertTrue(client.getPageAsText().contains("Data Loaded")); } // testing viewAction navigation @Test @InitialPage("/goto_result.xhtml") public void checkNavigation(JSFServerSession server, JSFClientSession client) throws IOException { Assert.assertEquals("/result.xhtml", server.getCurrentViewID()); Assert.assertTrue(client.getPageAsText().contains("Result page")); } The first test works, but the second one fails with the server.log stacktrace: 2011-07-12 09:23:20,116 DEBUG [org.jboss.seam.faces.event.PhaseEventBridge] (http-localhost%2F127.0.0.1-8080-2) Fired event [javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl@46ffcd87]] with qualifiers [[Ljava.lang.annotation.Annotation;@38b9d37b] 2011-07-12 09:23:20,117 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/a6c419-34e7-45b1-bc37-e751a70a57c6].[FacesServlet]] (http-localhost%2F127.0.0.1-8080-2) Servlet.service() for servlet FacesServlet threw exception: java.lang.IllegalStateException: Context is already active at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:301) [:6.0.0.Final] at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:110) [:6.0.0.Final] at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:84) [:6.0.0.Final] at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:224) [:2.0.3-] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:95) [:2.0.3-] at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107) [:2.0.3-] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114) [:2.0.3-] at org.jboss.seam.faces.component.UIViewAction.broadcast(UIViewAction.java:405) [:] at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:781) [:2.0.3-] at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1246) [:2.0.3-] at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:77) [:2.0.3-] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97) [:2.0.3-] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114) [:2.0.3-] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308) [:2.0.3-] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [:6.0.0.Final] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final] at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67) [:6.0.0.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [:6.0.0.Final] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [:6.0.0.Final] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.Final] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final] at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final] at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final] at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.Final] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [:6.0.0.Final] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final] at java.lang.Thread.run(Thread.java:662) [:1.6.0_24] I verified this failure with a manually created example app (available in faces/examples on the develop branch).
          Hide
          bleathem Brian Leathem added a comment -

          Summary of an IRC conversation with Pete Muir and Ed Burns, and Lincoln Baxter:
          pmuir states this is a problem caused by making a re-entrant call on the thread to the faces lifecycle. The viewAction component does this by starting/executing a new JSF lifecycle within the existing JSF lifcycle:
          https://github.com/seam/faces/blob/develop/api/src/main/java/org/jboss/seam/faces/component/UIViewAction.java#L405

          With respect to re-entrancy, edburns says:
          edburns: JSF relies on the re-entrancy model model of the servlet spec
          pmuir: pre Servlet 3 that is quite clear, the servlet container will never reuse a thread before a request has ended
          pmuir: in Servlet 3 I believe that requests can be suspended
          edburns: the JSF spec has not been updated to account for the re-entrancy capabilities in Servlet 3.
          pmuir: weld assumes that we don't have re-entrancy

          Rather than trying to mess with Weld to allow this re-entrancy to work, I suggested the JSF EG discuss any changes required at the spec level to accommodate this behavior. Lincoln suggested:
          lincolnthree: in prettyfaces i just use a phase listener, unfortunately you lose out on the whole component tree goodness
          lincolnthree: I'm comfortable saying that I think viewAction is a hack to get around the real problem
          lincolnthree: which is that JSF doesn't support phase-level actions like a front-controller

          Show
          bleathem Brian Leathem added a comment - Summary of an IRC conversation with Pete Muir and Ed Burns, and Lincoln Baxter: pmuir states this is a problem caused by making a re-entrant call on the thread to the faces lifecycle. The viewAction component does this by starting/executing a new JSF lifecycle within the existing JSF lifcycle: https://github.com/seam/faces/blob/develop/api/src/main/java/org/jboss/seam/faces/component/UIViewAction.java#L405 With respect to re-entrancy, edburns says: edburns: JSF relies on the re-entrancy model model of the servlet spec pmuir: pre Servlet 3 that is quite clear, the servlet container will never reuse a thread before a request has ended pmuir: in Servlet 3 I believe that requests can be suspended edburns: the JSF spec has not been updated to account for the re-entrancy capabilities in Servlet 3. pmuir: weld assumes that we don't have re-entrancy Rather than trying to mess with Weld to allow this re-entrancy to work, I suggested the JSF EG discuss any changes required at the spec level to accommodate this behavior. Lincoln suggested: lincolnthree: in prettyfaces i just use a phase listener, unfortunately you lose out on the whole component tree goodness lincolnthree: I'm comfortable saying that I think viewAction is a hack to get around the real problem lincolnthree: which is that JSF doesn't support phase-level actions like a front-controller
          Hide
          bleathem Brian Leathem added a comment -

          With respect to this working with earlier versions of Mojarra (2.0.3), Sebastian Sachtleben kindly tried out the viewAction example app in his setup, and confirmed that it doesn't work.

          Further investigation revealed that his application used PrettyFaces navigation in the backing methods of his viewAction, which is most likely why it works for him.

          Show
          bleathem Brian Leathem added a comment - With respect to this working with earlier versions of Mojarra (2.0.3), Sebastian Sachtleben kindly tried out the viewAction example app in his setup, and confirmed that it doesn't work. Further investigation revealed that his application used PrettyFaces navigation in the backing methods of his viewAction, which is most likely why it works for him.
          Hide
          aogier Anthony O. added a comment -

          It seems I encountered the same bug here, I'm not using PrettyFaces and I'm using JBoss 7.0.2.Final which seems to use Mojarra 2.1.3 (SNAPSHOT 20110825) (but is it really linked with Majorra ?)

          Show
          aogier Anthony O. added a comment - It seems I encountered the same bug here , I'm not using PrettyFaces and I'm using JBoss 7.0.2.Final which seems to use Mojarra 2.1.3 (SNAPSHOT 20110825) (but is it really linked with Majorra ?)

            People

            • Assignee:
              bleathem Brian Leathem
              Reporter:
              ssachtleben Sebastian Sachtleben
            • Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:

                Development