-
1. Re: Weld Conversation doesn't work well with JSF ajax calls
wangliyu Jul 21, 2011 8:55 AM (in response to 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. -
2. Re: Weld Conversation doesn't work well with JSF ajax calls
lutchobandeira Aug 23, 2012 8:37 AM (in response to wangliyu)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.
-
3. Re: Weld Conversation doesn't work well with JSF ajax calls
mkouba Aug 24, 2012 3:29 PM (in response to wangliyu)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.
-
4. Re: Weld Conversation doesn't work well with JSF ajax calls
mkouba Aug 24, 2012 3:32 PM (in response to 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).
-
5. Re: Weld Conversation doesn't work well with JSF ajax calls
mkouba Aug 28, 2012 5:01 AM (in response to wangliyu)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...
-
6. Re: Weld Conversation doesn't work well with JSF ajax calls
stupserich Oct 1, 2012 3:24 PM (in response to mkouba)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.
-
7. Re: Weld Conversation doesn't work well with JSF ajax calls
weinanli Jan 27, 2013 11:23 AM (in response to wangliyu)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 :-)
-
8. Re: Weld Conversation doesn't work well with JSF ajax calls
mkouba Jan 28, 2013 3:02 AM (in response to weinanli)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.
-
9. Re: Weld Conversation doesn't work well with JSF ajax calls
weinanli Jan 28, 2013 11:49 AM (in response to mkouba)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.
-
10. Re: Weld Conversation doesn't work well with JSF ajax calls
mkouba Jan 29, 2013 4:02 AM (in response to weinanli)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()
andaction
attribute ofh: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."
-
11. Re: Weld Conversation doesn't work well with JSF ajax calls
weinanli Jan 29, 2013 6:28 AM (in response to mkouba)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!