8 Replies Latest reply on Aug 10, 2006 11:36 AM by connerjohn

    Resume Pageflow after Conversation Timeout

    connerjohn

      Is there a way to resume a pageflow after a converstation has timed out?

      When this occurs, right now we can redirect to a no-conversation-view-id. However, this performs a redirect and resets the PageContext and we then lose the pageflow name/node.

      I would like to call an sfsb.action so that I can "reinitialize" the conversation and proceed. Thoughts on how to do this?

      If this is something that requires a code change, pointers on where to change would be appreciated. I'm going to start looking at it now. After placing a couple of debug points, it looks like I need to modify the Manager

      2006-08-07 12:24:41,812 DEBUG [org.jboss.seam.core.Manager] ===============================================================================
      2006-08-07 12:24:41,812 DEBUG [org.jboss.seam.core.Manager] found in PAGEFLOW noConversationViewId[null]
      java.lang.Exception
       at org.jboss.seam.core.Manager.redirectToNoConversationView(Manager.java:1064)
       at org.jboss.seam.jsf.AbstractSeamPhaseListener.restoreAnyConversationContext(AbstractSeamPhaseListener.java:49)
       at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:66)
       at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:89)
       at org.apache.myfaces.lifecycle.LifecycleImpl.restoreView(LifecycleImpl.java:181)
       at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:66)
       at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at com.itsolut.servlet.LoggingFilter.doFilter(LoggingFilter.java:30)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
       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.seam.servlet.SeamExceptionFilter.doFilter(SeamExceptionFilter.java:45)
       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.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
       at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
       at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
       at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
       at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
       at java.lang.Thread.run(Thread.java:595)


      --jc

        • 1. Re: Resume Pageflow after Conversation Timeout
          pmuir

          Surely you will have lost all the data associated with the pageflow at this point (e.g. any updates to entities will be lost) so the pageflow would have to start again? If you can come up with a sensible usecase the seam team is normally very good at applying a fix.

          • 2. Re: Resume Pageflow after Conversation Timeout
            connerjohn

             

            "petemuir" wrote:
            Surely you will have lost all the data associated with the pageflow at this point (e.g. any updates to entities will be lost) so the pageflow would have to start again?


            I agree. However, shouldn't the data from previous steps be saved in the database (I'm not doing anything with transactions to delay saving) automatically by Seam.

            But beyond that, what I'm looking for is the ability to specify an action method to execute instead of the no-conversation-view-id. I am using the no-conversation-view-id now and redirecting to an action in pages.xml which executes an SFSB method and then returns an outcome for a new *.xhtml page. However, it would be a lot better and more contained if I could just specify the action in the pageflow definition itself - similar to the no-conversation-view-id.

            Right now I am just restarting the pageflow in the pages.xml action. However, for the right pageflow process, the SFSB method called could be smart enough to "setup" the conversation state (and entirely up to the developer to make sure the state was restored correctly).

            The example I am working through is a shopping cart checkout process. If the user is on page3 (e.g., filling out the credit card info) and they get distracted and leave the computer for an hour, the conversation on the server times out (or maybe the server got restarted). Then, I currently send them back to the beginning (which is to login) of the pageflow using no-conversation-view-id.

            However, my pageflow is such that I could "restart" the pageflow if I could call a method that would load the Cart from the database which in this usecase would be all that is required to re-initialize the SFSB state. I would then like the last node to be displayed (in this example page3.xhtml). Ideally I would display some type of FacesMessage and the data would be populated on the form based on what they submited.

            Now the user would have to re-enter the information on page3 and submit; but they do not have to re-do the entire pageflow up to that point.

            Some might argue that the user should have to login if they have not be active for a period of time. I agree; but this time period is longer than a conversation timeout. And then what about server reboots - albiet that is probably an edge case that hopefully doesn't occur very often - but all the edge cases is what makes programming interesting.

            Just some food for thought,
            --jc

            • 3. Re: Resume Pageflow after Conversation Timeout
              pmuir

               

              "connerjohn" wrote:

              I agree. However, shouldn't the data from previous steps be saved in the database (I'm not doing anything with transactions to delay saving) automatically by Seam.


              Yup of course. I use pageflows for wizards, so only save to the database at user controlled points (normally the finish button at the end!).


              But beyond that, what I'm looking for is the ability to specify an action method to execute instead of the no-conversation-view-id. I am using the no-conversation-view-id now and redirecting to an action in pages.xml which executes an SFSB method and then returns an outcome for a new *.xhtml page. However, it would be a lot better and more contained if I could just specify the action in the pageflow definition itself - similar to the no-conversation-view-id.

              Right now I am just restarting the pageflow in the pages.xml action. However, for the right pageflow process, the SFSB method called could be smart enough to "setup" the conversation state (and entirely up to the developer to make sure the state was restored correctly).


              Well I think that sounds like a reasonable request; start a pageflow on conversation timeout, and then populate the conversation with whatever information you want. This could be via an action method or perhaps the name of the pageflow to start.

              I think the normal proceedure for this is to put it in JIRA.

              • 4. Re: Resume Pageflow after Conversation Timeout
                connerjohn

                Added as http://jira.jboss.org/jira/browse/JBSEAM-328

                Altough, if there was some guidance about how to add this to Seam, I would probably take a crack at it since I would like this sooner than later.

                Thanks,
                --jc

                • 5. Re: Resume Pageflow after Conversation Timeout
                  gavin.king

                  in CVS, it is possible to call Pageflow.instance().reposition(node).

                  Is that good enough?

                  • 6. Re: Resume Pageflow after Conversation Timeout
                    connerjohn

                     

                    "gavin.king@jboss.com" wrote:
                    in CVS, it is possible to call Pageflow.instance().reposition(node).

                    Is that good enough?


                    Definitely fast enough! Thanks.

                    I will check it out. After having looked at it for a bit, I'm very interested to see how it was implemented.

                    Thanks
                    -- jc

                    • 7. Re: Resume Pageflow after Conversation Timeout
                      denis-karpov

                       

                      However, shouldn't the data from previous steps be saved in the database

                      I think if you need to persist state into database you should consider to use jBPM. Although page flows use the same engine, page flows save its state only in conversation context.

                      • 8. Re: Resume Pageflow after Conversation Timeout
                        connerjohn

                         

                        "denis-karpov" wrote:
                        However, shouldn't the data from previous steps be saved in the database

                        I think if you need to persist state into database you should consider to use jBPM. Although page flows use the same engine, page flows save its state only in conversation context.


                        Of course your right, the state of the pageflow is not saved. I should have been a bit clearer. I meant the state of the entity beans held by the SFSB. The changes to the SFSB entities are stored in the database based on the transaction semantics for the SFSB. In this case is managed by Seam, which saves the changes to the db on every Http Request.

                        --jc