Basically what I expect to obtain is this: Clicking on one of the three links I start a conversation, then, clicking on the doIt link see the list of strings to grow; unfortunately this is true only in the third case (when the id is generated by Seam), both in the first and in the second Seam seems to not bind the component to the conversation, indeed, running test on the component instance two, when I click on the doIt link, I read in the log this print:

but the list does not grow, moreover if I create the list of strings in the @Begin method (as I do in the third example) the doIt method fails with a NullPointerException because the list is not present.

That's it. Is this a bug?

Two questions on conversation management: - Can I expect that if I click say on the second link (the static id.. not correct but to understand) Seam will understand that I'm asking for that conversation and resumes it? - Is it legal to use the Redirect API knowing the conversation id (regardless generated or explicit) in order to redirect to that conversation? Both the questions without a LRC in place (s:conversationPropagation type="none")

You have defined this page to use a natural conversation id, and then you try to use other strategies *on the same page*??

Definitely no. Three Seam components, three pages, three navigation rules, to avoid any misunderstanding I created three separate projects too and made the tests again. One project defines the conversation id in a natural way, another one defines it in the old fashion and the third one gets a generated conversation id. The three projects have the same behaviour: One link from the main page to the @Begin action of the conversation, from that link I move through the navigation rules in another page, the one related to that conversation.

The s:link refers to an action of the Seam component actionTwo, such action simply adds a string to a list, I guess I'm in a LRC, the @Begin method of the actionTwo component returned the outcome of this page, the s:link propagate the conversation, then I expect that Seam holds the component (saved in the conversation context) in the current conversation, but this does not happen in the two test cases with explicit conversation id. In the Seam-assigned conversation id test everything works properly.

I can post you both the test cases and a more detailed description, anyway, I don't think you need server logs of Seam.

Can you please answer to these two questions?

- Can I expect that if I click twice on a link connected to the start conversation of an explicit id conversation Seam will understand that I'm asking for that conversation and resumes it?- Is it legal to use the Redirect API knowing the conversation id (regardless generated or explicit) in order to resume a conversation?

Both the questions without a LRC in place (s:conversationPropagation type="none")

Actually my application does not work with Seam 1.2.1, I'd like to move to a natural conversation id compliant usage and I want to avoid any misunderstanding of the framework.

It made me crazy but I found it. It was a problem with my configuration faces-config.xml / pages.xml.I was doing almost the same thing of the booking sample (booking confirmation) and there I found the solution: I moved the navigation rules in the pages and (I think this is the reason) redirected the requests.

But I'm facing another problem (or I'm doing something else wrong):

In the booking sample language (meaningless for the sample but to show the scenario):I would like to include the hotel search result list in the template (having it visible also in the booking page) and I would like to select another hotel from the booking, and then start the new conversation having the same view-id, same action but using hotel.id to create different conversation id, through the conversation-param EL).

To achieve this I blocked the conversation propagation in the hotel selection <s:link>, something like this:

The effect is this: - the first time everything is ok, conversation started, promoted as a long running and so on... - when I try to book more than once Seam is unable to recognize (does not evaluate the EL #{myhotel.id}) and assigns a generated id but starts the conversation, promotes it as a long running...

Can I achieve this with explicit natural conversation id? Am I doing something wrong or is a bug?

also the effect is different: - the first ok - the second time it does not render the page (comes back to the main.xhtml) - the third ok ...

in the even calls Seam intercepts (through the RootInterceptor) the parameter-value EL expression, evaluates it and creates the correct (with the correct conversation id) url to redirect to but neither redirects to the myaction page nor with that conversation id.