slink join and conversationID

[vanyatka]

Hi,

Must be something rather obvious, yet I'm not aware of it. I have a page with a s:link element with propagation "join" and "conversation.id" output.

When I first load the page I see conversation as 1 which is fine. But when I click the link the conversation ID increases to 2, regardless of the propagation "join". In next clicks it stays the same on 2, which is as expected.

Can anyone shed a light on why the first click is different from all the latter's? Is it a JSF feature I don't know about?

ps. I never worked with JSF before, is it absolutely necessary to know all the intricacies of JSF in order to write Seam apps?

Thanks,

[jacob.orshalick]

When you say you have conversation.id output, what do you mean? Are you seeing the cid in the URL? When the view is displayed and you mouse over the link you should see the current conversationId as a query parameter (in your example conversationId=1 or if you have customized the id parameter cid=1).

"vanyatka" wrote:
ps. I never worked with JSF before, is it absolutely necessary to know all the intricacies of JSF in order to write Seam apps?

It is not necessary to know all the intracacies of JSF to write Seam apps :) Seam abstracts most of the details of JSF so you don't have to worry about them making it very easy to develop applications.

[vanyatka]

I mean I simply have outputText element showing conversation.id.
After the page is loaded the first time the conversation ID shows 1 and the link as I see it in the browser's status bar is

.../home.seam?cid=1&conversationPropagation=join

But when I click the link the conversation ID goes up to 2, and the link changes to

.../home.seam?cid=2&conversationPropagation=join

From the second click onwards the page doesn't change.

It is not necessary to know all the intracacies of JSF to write Seam apps :) Seam abstracts most of the details of JSF so you don't have to worry about them making it very easy to develop applications.

That's encouraging. I find it frustrating to spend time on something which you'll abandon and forget later. As far as I can tell many bits of JSF are now being replaced and enhanced, particularly by Seam.

[jacob.orshalick]

Ok, so did you begin a long-running conversation with cid 1? By default, Seam is always going to create a conversation for the processing of a request, but you must promote that conversation to long-running if you want it to continue. join=true will start a long-running conversation if there is no long-running conversation to join.

Also, have you checked the seam.debug page? Is conversation with id 1 sticking around in memory?

[vanyatka]

"jacob.orshalick" wrote:
Also, have you checked the seam.debug page? Is conversation with id 1 sticking around in memory?

Thanks for this tip, the debug page is vastly helpful!

[vanyatka]

"jacob.orshalick" wrote:
Ok, so did you begin a long-running conversation with cid 1? By default, Seam is always going to create a conversation for the processing of a request, but you must promote that conversation to long-running if you want it to continue. join=true will start a long-running conversation if there is no long-running conversation to join.

The issue is that I'm not being able to promote a "regular" conversation to a long-running one while keeping the ID of the original conversation. When I link a page to itself with s:link propagation="begin", then a new long-running conversation is created, but it has the different conversationID to the original one, so I presume this means that it's become a different conversation, and what particularly worries me is that SMPC of the original conversation is lost.

[jacob.orshalick]

"vanyatka" wrote:
When I link a page to itself with s:link propagation="begin", then a new long-running conversation is created, but it has the different conversationID to the original one

If by the original one you mean the conversation that existed on the last page rendering, this behavior is expected. This is because as I said, Seam creates a temporary conversation on each request that only exists for the duration of the request. So, once the response is rendered, unless that conversation has been promoted to long-running, it will no longer be maintained (which is why you are seeing this behavior). The conversationId you are seeing in the outputText is gone (unless it was promoted).

On the next request (s:link propagation="begin") another temporary conversation is created (with the new id) and this conversation is promoted to long-running. It sounds like you should begin the long-running conversation the first time the page is accessed if you want to carry the SMPC. This can be accomplished in several ways: @Begin, through pages.xml action, etc.

I hope this helps.

[vanyatka]

Thanks, Jacob. I got the idea! Now gonna try it out :)
(I wish I could award you some duke dollars, or whatever is it called :)

[jacob.orshalick]

LOL. Just pay it forward as you get more familiar with Seam :) Active forums are important for a project's success!