The spec only speaks of propagating non-transient conversations over redirects with the cid parameters so I would assume this is intended.
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.
Could you destroy the conversation before you leave the original page? For instance, the method which returns
page2back 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).
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.
Lets hope Dan Allen picks up on this thread as he's more of the JSF/Servlet lifecycle wizard than me.
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
betterflash scope, however it seems that here the flash scope would work exactly as intended, while conversation scope wouldn't.
Just to confirm, using the flash scope fro Seam3-faces works, that is, it's a context that survives the redirect.