-
1. Re: Conversation support: Why only for JSF?
asookazian Nov 17, 2009 11:29 PM (in response to luxspes)or how bout conversation support for Wicket or Tapestry or GWT or Flex?
-
2. Re: Conversation support: Why only for JSF?
htle81.hle.bravurasolutions.com Nov 18, 2009 1:16 AM (in response to luxspes)Section 5.3.2 of the reference manual seems to indicate that you can manually propagate the conversation with a non-faces request by including the unique identifier of the conversation as a request parameter. It is nicer with JSF because this happens automatically.
-
3. Re: Conversation support: Why only for JSF?
luxspes Nov 18, 2009 1:24 PM (in response to luxspes)But ConversationPropagationFilter seems to have a hard coded dependency with JSF... does that mean I need to have the .jars of JSF copied in to my project even if I am not going to use it ever?
-
4. Re: Conversation support: Why only for JSF?
nickarls Nov 18, 2009 1:49 PM (in response to luxspes)There will probably be a SPI for common conversation propagation.
-
5. Re: Conversation support: Why only for JSF?
luxspes Nov 18, 2009 2:52 PM (in response to luxspes)Shoudn't it be the other wat around: common stuff as part of weld and the particular for some other tech as an SPI extension?
-
6. Re: Conversation support: Why only for JSF?
luxspes Nov 18, 2009 4:04 PM (in response to luxspes)Mmmm, acording to the docs:
The conversation context is active during any JSF request.Guess that decides it, Conversations are (for now) only for JSF. Guess it is time for a feature request in JIRA ;-)
Most conversations are destroyed at the end of the request. If a conversation should hold state across multiple requests, it must be explicitly promoted to a long-running conversation.Oh, so Seam nomenclature gets altered? now they are not
temp conversations
andlong-running conversations
, but only:conversations and long-running conversations
. That is unexpected since the last time I discussed about that people seem to regardtemp. conversations
asnot-conversations
. -
7. Re: Conversation support: Why only for JSF?
luxspes Nov 18, 2009 4:11 PM (in response to luxspes)And so I create the request WELD-295
-
8. Re: Conversation support: Why only for JSF?
luxspes Nov 18, 2009 4:40 PM (in response to luxspes)After reading Chapter 20 Alternative view layers I found this:
20.1.2. Conversations with Wicket
Wicket can also take advantage of the conversation scope from CDI, provided by the Wicket extension module.After reading the code in org.jboss.weld.wicket.WeldRequestCycle I see it uses javax.enterprise.context.Conversation
So now I am confused... Is the implementation of Conversations in Weld dependant on JSF or not? Do I need to have JSF .jars in my Wicket for conversations to work property?
In another thread Gavin told me that:
Now, perhaps we got the line sightly wrong first time around - people are already yelling at me for not supporting injection of FacesContext out-of-the-box - and if so, we can fix it by adding a couple more objects to the list in section 3.6 of the spec.While it would have been great to have Weld proportionate everything Seam proportionates, I think, a very clear line should be painted to prevent bloating. I think Weld should get thinner, and its boundaries clearly defined: For example, I think a weld-jsf.jar should be created (the JSF equivalente of weld-wicket.jar) to cleanly and clearly separate the part of Weld that is JSF dependant (and the part that is not)
What do you think about that?
-
9. Re: Conversation support: Why only for JSF?
luxspes Nov 18, 2009 4:45 PM (in response to luxspes)And so WELD-297 is created
-
10. Re: Conversation support: Why only for JSF?
paulmooney Nov 18, 2009 6:25 PM (in response to luxspes)I was going through some of the wicket-weld source code (I love how netbeans with maven grabs all the source for me automatically!) and found that there is a mechanism in the WeldApplication code for passing along the conversation id (CID) on form submits. So I'm assuming this means conversations are supported in Wicket, but I haven't tried it so I can't be sure.
-
11. Re: Conversation support: Why only for JSF?
luxspes Nov 18, 2009 7:35 PM (in response to luxspes)
Paul Mooney wrote on Nov 18, 2009 18:25:
I was going through some of the wicket-weld source code (I love how netbeans with maven grabs all the source for me automatically!) and found that there is a mechanism in the WeldApplication code for passing along the conversation id (CID) on form submits.Yes but...
So I'm assuming this means conversations are supported in Wicket, but I haven't tried it so I can't be sure.The questions is: are they supported in Wicket even if no JSF .jar is available in the classpath? And if they are, and having Conversations without JSF is so easy in Weld... why the warning in ConversationPropagationFilter?
-
12. Re: Conversation support: Why only for JSF?
nickarls Nov 18, 2009 8:23 PM (in response to luxspes)Well, I think it's mostly to tell it's not a generic web filter.
You can write your own conversation manager (have a look in weld-api, ConversationManager and the ServletConversationManager in core), cid is just a token passed around an a small associated wrapped object with some state)
-
13. Re: Conversation support: Why only for JSF?
pmuir Dec 15, 2009 6:35 PM (in response to luxspes)Conversations are supported in Weld's Wicket extension when used with Weld as the CDI container. If you try to use it with OWB for example, conversations won't work. Until the spec has a conversation manager we can't do much about this :-(