Weld Conversation doesn't work well with JSF ajax calls

[wangliyu]

I'm using the latest Weld (1.1.1.Final), and I found the Weld doesn't work (or at least not well) with JSF ajax/RichFaces a4j calls.
And I'm not sure if this is by design or a bug?
The problem is when I begin the conversation, Weld requires to sent the cid to the client and next get will bring that CID back, and WeldPhaseListener will active the LRC according to the CID in the requestMap. the ajax call pretty much same with normal get call, the only problem is that it doesn't the store the sentback CID, so next time when it fire the request, the WeldPhaseListener doesn't have the cid, so it begin a new transient conversation rather than active the previous LRC.

Right now it's pain in the butt, the work around is to store that cid as a hidden field in the next form. I think it's not the right approach. Should Weld store the cid somewhere in a internal session scope bean? so it doesn't require bring the cid back and force?

[wangliyu]

I kind of understand why the conversation ID has to carry back to the client, because the CDI try to support multiple conversation within the same session. but in my application, I always using named conversation (and there is only one conversation at the same time).

So I still have no clue how to fix the problem.
Long in short, with JSF ajax calls, the conversation doesn't propergate properly.

[lutchobandeira]

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.

[mkouba]

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.

[mkouba]

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).

[mkouba]

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...

[stupserich]

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.

[weinanli]

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 :-)

[mkouba]

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.

[weinanli]

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.

[mkouba]

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."

[weinanli]

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!