7 Replies Latest reply on Mar 22, 2010 8:16 PM by Adam Warski

    Transient conversation propagation

    Paul Bakker Newbie

      I'm trying to implement a simple Post-then-redirect with JSF 2 and Weld. My managed bean is conversation scoped (transient).

      public class HelloBean implements Serializable {

      I redirect to a new JSF view from an action using the navigation rules in faces-config:


      Data on the managed bean is not available any more on page2 however. I expected the transient conversation would be destroyed AFTER rendering the new view. If I upgrade the conversation to long running it works, but I would have to write some code to explicitly destroy the conversation after rendering.

      Is this intended behavior?

        • 1. Re: Transient conversation propagation
          Nicklas Karlsson Master

          The spec only speaks of propagating non-transient conversations over redirects with the cid parameters so I would assume this is intended.

          • 2. Re: Transient conversation propagation
            Paul Bakker Newbie

            You're right, I can also not find any more explicit notes about it. It also says a transient conversation is destroyed at the end of the request. Is this after a redirect is done, or after any view is rendered? In the weld docs there is something about this pattern, but not saying anything about the need of a long-running conversation. That doesn't mean it should work with a transient conversation, but also not that it shouldn't work. So I'm still not completely sure.

            What would be the best way for ending a long running conversation when rendering the new page?
            I see the following possibilities:

            - Use a JSF event to call the end method.

            - Set the timeout of the conversation to a few seconds when calling the begin method. Because the next view should be rendered within a few seconds this would work, while still making sure the conversation is destroyed.

            Both require some extra work, I guess a portable extension could solve this in an easier way.

            • 3. Re: Transient conversation propagation
              Ian R Newbie

              Could you destroy the conversation before you leave the original page? For instance, the method which returns page2 back to JSF? If I know the conversation is not needed in the next page, I explicitly destroy it. More code I know, but then it is known (I hide it in a utility method, as I do it quite frequently).

              • 4. Re: Transient conversation propagation
                Paul Bakker Newbie

                No that would only work if the ended conversation's state is preserved until after rendering the new page, which doesn't seems to be case with a redirect. This was my initial solution too after finding the problem with the transient conversation. It makes sense too; if a transient conversation is destroyed before rendering the new (redirected) page, an ended long-running conversation should be too.

                • 5. Re: Transient conversation propagation
                  Nicklas Karlsson Master

                  Lets hope Dan Allen picks up on this thread as he's more of the JSF/Servlet lifecycle wizard than me.

                  • 6. Re: Transient conversation propagation
                    Adam Warski Master

                    Heh, I just wanted to post no exactly the same problem.

                    In Seam, the transient conversation always spanned both requests (before and after the redirect), unless on redirect the end-conversation-before-redirect parameter was set. So the question really is, how to get the Seam behavior?

                    Also, the docs suggest that the conversation scope is a better flash scope, however it seems that here the flash scope would work exactly as intended, while conversation scope wouldn't.


                    • 7. Re: Transient conversation propagation
                      Adam Warski Master

                      Just to confirm, using the flash scope fro Seam3-faces works, that is, it's a context that survives the redirect.