9 Replies Latest reply on Jul 10, 2006 4:47 PM by Gavin King

    Problems with pages.xml...

    Ben Kyrlach Newbie

      I'm replacing part of a struts web application with Seam and I'm having some strange problems with pages.xml

      Problem one: I have a pages.xml that runs an action on pageload that grabs some request values and stores them in a session scoped Seam component so that I can use them later. However, when I preform any action on said page that would navigate me to a new page, the action defined for this page runs again. Since the request parameters are now lost, this results in all the values in my bean being nulled out, and my application throws null pointer exceptions.

      pages.xml

      <page view-id="/ben/infozap.xhtml" action="#{infozapAction.createInfoZapDTO}"/>


      InfoZap action:
      @Stateless
      @Name("infozapAction")
      @Interceptors(SeamInterceptor.class)
      public class InfozapActionImpl implements InfozapAction
      {
      @RequestParameter
      String[] schoolList;

      @RequestParameter
      String productAreaID;

      @RequestParameter
      String infozapType;

      @RequestParameter
      String productTypeID;

      @Out
      private InfoZapDTO izdto;

      //@In(create=true)
      //private Redirect redirect;

      public void createInfoZapDTO()
      {
      izdto = new InfoZapDTO();

      if(schoolList != null)
      {
      izdto.setSchoolList(schoolList);
      }

      if(productAreaID != null)
      {
      izdto.setProductAreaID(productAreaID);
      }

      if(infozapType != null)
      {
      izdto.setInfozapType(infozapType);
      }

      if(productTypeID != null)
      {
      izdto.setProductTypeID(productTypeID);
      }
      //redirect.setViewId("/ben/infozap.jsf");
      //redirect.execute();
      }
      }

      infozap.xhtml
      ...
      <h:commandButton action="#{someActionClass.someAction}"/>
      ...

      Problem two: In light of the above, I made a dummy page and edited the URL pattern in pages.xml to fire my action when the dummy page is navigated to. I edited the action to redirect to the correct page after it grabs the request values. I can see in my code that the method is fired, but even though I outject the member variable, after the redirect, it's no longer available

      pages.xml

      <page view-id="/ben/test.xhtml" action="#{infozapAction.createInfoZapDTO}"/>


      InfoZap action:
      same as above with redirect lines uncommented

      Any help would be greatly appreciated.

        • 1. Re: Problems with pages.xml...
          Ben Kyrlach Newbie

          Problem 3: So, trying it a new way, I had the pages action start a conversation by invoking a method with the following annotation...

          @Begin(id=1)

          in a stateful conversational bean. However, when submitting the form on the page, the following exception is thrown...

          14:15:21,805 ERROR [PhaseListenerManager] Exception in PhaseListener RENDER_RESPONSE(6) beforePhase.
          javax.faces.el.EvaluationException: Exception while invoking expression #{processInfozapAction.createInfoZapDTO}
          at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:153)
          at org.jboss.seam.core.Pages.callAction(Pages.java:169)
          at org.jboss.seam.core.Pages.callAction(Pages.java:151)
          at org.jboss.seam.jsf.AbstractSeamPhaseListener.callPageActions(AbstractSeamPhaseListener.java:135)
          at org.jboss.seam.jsf.AbstractSeamPhaseListener.beforeRender(AbstractSeamPhaseListener.java:106)
          at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:53)
          at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:70)
          at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:373)
          at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
          at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
          at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
          at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
          at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
          at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
          at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
          at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
          at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754)
          at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:684)
          at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:876)
          at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
          at java.lang.Thread.run(Thread.java:595)
          Caused by: javax.ejb.EJBException: java.lang.IllegalStateException: begin method invoked from a long running conversation, try using @Begin(join=true)
          at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69)
          at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
          at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:197)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
          at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
          at org.jboss.ejb3.stateful.StatefulInstanceInterceptor.invoke(StatefulInstanceInterceptor.java:81)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
          at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
          at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
          at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
          at org.jboss.ejb3.stateful.StatefulContainer.localInvoke(StatefulContainer.java:188)
          at org.jboss.ejb3.stateful.StatefulLocalProxy.invoke(StatefulLocalProxy.java:98)
          at $Proxy346.createInfoZapDTO(Unknown Source)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:585)
          at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:129)
          ... 32 more
          Caused by: java.lang.IllegalStateException: begin method invoked from a long running conversation, try using @Begin(join=true)
          at org.jboss.seam.interceptors.ConversationInterceptor.endOrBeginLongRunningConversation(ConversationInterceptor.java:44)
          at sun.reflect.GeneratedMethodAccessor299.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:585)
          at org.jboss.seam.util.Reflections.invoke(Reflections.java:16)
          at org.jboss.seam.interceptors.Interceptor.aroundInvoke(Interceptor.java:90)
          at org.jboss.seam.interceptors.SeamInvocationContext.proceed(SeamInvocationContext.java:60)
          at org.jboss.seam.interceptors.BusinessProcessInterceptor.manageBusinessProcessContext(BusinessProcessInterceptor.java:58)
          at sun.reflect.GeneratedMethodAccessor298.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:585)
          at org.jboss.seam.util.Reflections.invoke(Reflections.java:16)
          at org.jboss.seam.interceptors.Interceptor.aroundInvoke(Interceptor.java:90)
          at org.jboss.seam.interceptors.SeamInvocationContext.proceed(SeamInvocationContext.java:60)
          at org.jboss.seam.interceptors.ConversationalInterceptor.checkConversationForConversationalBean(ConversationalInterceptor.java:80)
          at sun.reflect.GeneratedMethodAccessor297.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:585)
          at org.jboss.seam.util.Reflections.invoke(Reflections.java:16)
          at org.jboss.seam.interceptors.Interceptor.aroundInvoke(Interceptor.java:90)
          at org.jboss.seam.interceptors.SeamInvocationContext.proceed(SeamInvocationContext.java:60)
          at org.jboss.seam.interceptors.RemoveInterceptor.removeIfNecessary(RemoveInterceptor.java:39)
          at sun.reflect.GeneratedMethodAccessor296.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:585)
          at org.jboss.seam.util.Reflections.invoke(Reflections.java:16)
          at org.jboss.seam.interceptors.Interceptor.aroundInvoke(Interceptor.java:90)
          at org.jboss.seam.interceptors.SeamInvocationContext.proceed(SeamInvocationContext.java:60)
          at org.jboss.seam.interceptors.ExceptionInterceptor.handleExceptions(ExceptionInterceptor.java:40)
          at sun.reflect.GeneratedMethodAccessor295.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:585)
          at org.jboss.seam.util.Reflections.invoke(Reflections.java:16)
          at org.jboss.seam.interceptors.Interceptor.aroundInvoke(Interceptor.java:90)
          at org.jboss.seam.interceptors.SeamInvocationContext.proceed(SeamInvocationContext.java:60)
          at org.jboss.seam.ejb.SeamInterceptor.aroundInvokeInContexts(SeamInterceptor.java:73)
          at org.jboss.seam.ejb.SeamInterceptor.aroundInvoke(SeamInterceptor.java:45)
          at sun.reflect.GeneratedMethodAccessor351.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:585)
          at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
          at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
          at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
          at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
          at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
          at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
          at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
          ... 52 more

          This is wrong according to the Seam documentation, which says that if you call the @Begin method of a conversational bean and the id expression evaluates to the same id as the current conversation, that the @Begin method will be skipped, and you'll join the currently in progress conversation.

          Please help.

          • 2. Re: Problems with pages.xml...
            Gavin King Master

            If the page action begins the conversation, there is already a conversation - so you should not have a @Begin annotation on the form action method.

            This is not in any way contrary to the documentation.

            • 3. Re: Problems with pages.xml...
              Ben Kyrlach Newbie

              Gavin...

              I think you misunderstood me. There is no form action that starts a conversation. That method annotated with @Begin is the method that the page action is calling... not the form action. Either way, the documentation clearly states that calling a method annotated with @Begin(id="something") where something = a currently running conversation id that the user session will seamlessly join the conversation and the @Begin method will never be invoked.

              What's happening for me is that any form action is causing the page action to be run again... which is causing the @Begin annotated method to be called again. Even though this method is given a hard coded conversation ID, it's still throwing this exception.

              Sorry if I was unclear.

              • 4. Re: Problems with pages.xml...
                Gavin King Master

                OK then, but you typed:

                However, when submitting the form on the page, the following exception is thrown


                Is it thrown when you render the page, or when you submit the form?

                Anyway, AFAICT, the exception is being thrown because you already have a long-running conversation associated with the request when the @Begin method is called.

                Remove the "id=1" bit, I'm sure the exception still occurs. (Unless you are calling the method twice, of course.)

                (If it goes away, then yes, that would be a bug.)

                • 5. Re: Problems with pages.xml...
                  Ben Kyrlach Newbie

                  It's happening when right before the render-response phase after a form submission. I guess I'm still misunderstanding the way conversation works. It definitely still throws the exception when I remove the (id=1) part. I'm not sure what you mean by "calling the method twice", but either way, I'm trying a different solution now. It doesn't make sense to me that the page action is getting invoked again after the form submission.

                  Anyways, thanks for your help so far.

                  • 6. Re: Problems with pages.xml...
                    Gavin King Master

                    Right, i think what you are telling me is that the page action is called twice: once when we first navigate to the page, and again when we submit the form.

                    The second time blows up, b/c it tries to start a conversation when one already exists. Right?

                    Page actions are called *every* time a view-id is rendered, not just during GET requests.

                    • 7. Re: Problems with pages.xml...
                      Gavin King Master

                      BTW, the problem is easily fixed by using @Begin(join=true)

                      • 8. Re: Problems with pages.xml...
                        Ben Kyrlach Newbie

                        Gavin...

                        Does @Begin(join=true) still invoke the code in the annotated method if you're joining an existing conversation? If not, that definitely would be a solution to my problem. Either way, what you just said pointed me to the real problem (yes, I feel pretty dumb now). When I changed folder structure inside my web app, I forgot to update faces-config.xml where I had my navigation rules defined. This is most likely what was causing the page action to fire even when form actions were executed that should have resulted in navigating to a new page.

                        I was also misunderstanding the part of the documentation that said if you called an @Begin method where the (id="some el") "some el" expression evaluated to an already existing conversation ID to say that even if you were already in a conversation, that you'd be rejoined to that conversation. I'm now guessing that the documentation was speaking of a user who wasn't in a conversation at all, joining a still running conversation that the user had left without closing earlier during the user session.

                        Thanks again for your patience.

                        • 9. Re: Problems with pages.xml...
                          Gavin King Master

                           

                          Does @Begin(join=true) still invoke the code in the annotated method if you're joining an existing conversation?


                          Yes it does. I assumed that your method was basically a no-op.

                          I'm now guessing that the documentation was speaking of a user who wasn't in a conversation at all, joining a still running conversation that the user had left without closing earlier during the user session.


                          Right.