1 Reply Latest reply on Jul 5, 2007 1:46 PM by Gavin King

    seam conversations - conceptual design issues

    Wolfgang Schwendt Newbie

      Hello,

      (first of all excuse my bad English).

      when a conversationId is restored from the PageContext (this happens when a Faces request is received), the validateLongRunningConversation property of org.jboss.seam.core.ConversationPropagation is set to page.isConversationLongRunning().

      Consequently, in the case of a long-running conversation, org.jboss.seam.core.Manager.restoreConversation() returns true or false, depending on whether or not the conversation was successfully restored.


      In contrast, when a non-faces request is received, the conversationId is retrieved from the request parameters and the validateLongRunningConversation of org.jboss.seam.core.ConversationPropagation remains false.

      Consequently, in the case of a long-running conversation, org.jboss.seam.core.Manager.restoreConversation() always returns true, even when it was not possible anymore to restore the long-running conversation and a fresh temporary conversation was therefore created instead. (see the last line of org.jboss.seam.core.Manager.restoreConversation() ).

      // last line of org.jboss.seam.core.Manager.restoreConversation()
      
      public boolean restoreConversation()
      { ConversationPropagation cp = ConversationPropagation.instance();
      ...
      
       return restoreAndLockConversation(ce) || !cp.isValidateLongRunningConversation();
      }
      


      It follows that for non-faces requests we don't have a validation of long-running conversations.

      class org.jboss.seam.jsf.SeamPhaseListener {
      ...
      
       /**
       * Restore the page and conversation contexts during a JSF request
       */
       protected void afterRestoreView(FacesContext facesContext)
       {
       FacesLifecycle.resumePage();
       Map parameters = facesContext.getExternalContext().getRequestParameterMap();
       ConversationPropagation.instance().restoreConversationId(parameters);
       boolean conversationFound = Manager.instance().restoreConversation();
       FacesLifecycle.resumeConversation( facesContext.getExternalContext() );
      
       // see my notes above: For non-faces requests conversationFound is
      // always true, even if the conversation was actually not found and a
      // temporary conversation was created
       if (!conversationFound)
       {
       Pages.instance().redirectToNoConversationView();
       }
      



      I thought about what could be Gavin's intention that there is no validation of long-running conversations when a non-faces request is received.
      Perhaps the reason is that URLs are bookmarkable and the user could bookmark a URL that contains a conversationID of a long-running conversation. If the user then makes a request with this bookmarked URL, he would not be able to access the corresponding page if the conversationID contained in the URL was validated.

      But we pay a big price if we simply give up the validation of long-running conversations. I think it would be much better if the last line of
      org.jboss.seam.core.Manager.restoreConversation() was simply as follows:


       // last line of org.jboss.seam.core.Manager.restoreConversation()
      
      public boolean restoreConversation()
      { ConversationPropagation cp = ConversationPropagation.instance();
      ...
      
       return restoreAndLockConversation(ce);
      }
      



      In order to support bookmarkable URLs where a contained conversation ID should not be validated, we could simply add another request parameter to indicate that restoreConversation should return true even if the long-running conversation couldn't be successfully restored.


      Please give us the same validation behavior for non-faces requests as we have for faces requests!