Hello, did you find a solution for this problem? I am with a similar problem, I want a good way to propagate the cid on ajax calls.

I think it's a bug (not sure whether on RichFaces or JSF impl) because the CDI spec states that "The long-running conversation context associated with a request that renders a JSF view is automatically propagated to any faces request (JSF form submission) that originates from that rendered page". In other words JSF should propagate the conversation id automatically.

Anyway I would use JSF f:param tag as a workaround. This way is pretty legal IMHO.

<a4j:commandLink value="Foo" action="#{foo.doSomething}">
    <f:param name="cid" value="#{javax.enterprise.context.conversation.id}" />
 </a4j:commandLink>

I will expand the related CDI TCK test to test ajax calls and identify the cause as well.

Actually I did some tests with plain JSF2 and it works as expeceted. However when using ajax you always have to be sure to define correct rerendering. For every ajax call you'll have to rerender either the whole form (the action URL will have conversation id appended) or at least components using cid (the example in previous comment).

In fact the CDI/JSF2/RF4 stack works quite differently than Seam2/JSF/RF3 when it comes to conversation propagation. Mainly because CDI does not know page/view scope (better said has not such built-in scope) that was also used in Seam2 to restore conversations so that the cid param was not always required. Maybe this could change in CDI 1.1...

Have you been able to propagate a conversation for <a:mediaoutput> ? I'm not sure if it's a bug or whether I'm simply too supid to configure it properly.

Hi Wang,

     I've written a document on how to make JSF2 Ajax + Conversation Scope work properly: https://docs.jboss.org/author/display/AS71/Using+JSF2+Ajax+library+together+with+CDI+ConversationScope+in+JBoss+AS7+%28Draft%29

     Hope this could help you :-)

Hi Weinan Li,

actually I find your solution a little bit compilated. Check the workaround I refer to in my blogpost: Seam vs Weld: ajax and conversations in JSF views.

Hi Martin, thanks for providing your solution :-) It's simpler but have two limitations:

1. It must have a 'Start Conversation' Button to kick off. For end users this is weird because they must understand what does 'conversation' mean.

2. Users must click 'start conversation' before clicking any other functions, if they don't do so they will get conversation not found exception.

You're right :-), the limitation is that Weld (not sure of other impls) tries to restore the long-running conversation even if the cid param is empty, which doesn't make sense IMHO.

One thing I don't understand in your example is how do jsf.ajax.request() and action attribute of h:commandButton work together...

Nevertheless, this (conversations and AJAX in the context of CDI) should be fixed, because the CDI 1.0 spec already states:

"The long-running conversation context associated with a request that renders a JSF view is automatically propagated to any faces request (JSF form submission) that originates from that rendered page."

1. "restore the long-running conversation even if the cid param is empty" - I totally agree with you this is a bug :-) Could you please file a JIRA to WELD to see if it could be fixed?
2. "how do jsf.ajax.request() and action attribute of h:commandButton work together" - Just use the 'onclick' event is okay, or you can also use the 'jsScript' function provided by Richfaces. I'm trying to avoid using and additional js libraries in my example to keep the project minimum. Acutally using Richfaces + Prototype you can make this example much simpler.
3. "conversations and AJAX in the context of CDI) should be fixed" - Totally agree with you! But I'm really busy on RESTEasy dev/Fedora packaing and EAP6 work. If possible please file a JIRA to see if the WELD team could fix it. Thanks a lot!