Need a good Weld Conversation (@ConversationScoped) tutorial

[ifischer]

I understand what the Conversation and @Conversationscoped is about. But after playing around with conversations for a while, reading the Weld-Doc and some blog posts, i feel like i still don't really understand how to use conversations correctly in my JSF2-Weld-(EJB)-App.
To see how to use them in practice, i would really like to read some more tutorials and examples, but the net seems to lack of good examples.

In the examples of the current Weld Release (1.0.1-Final), i also couldn't find anything about conversations.
Am i missing a good tutorial out there?
Any help appreciated!

[nickarls]

Woiking on it: https://jira.jboss.org/browse/WELD-439

Reza had a tutorial recently on TSS: http://www.theserverside.com/tip/Dependency-Injection-in-Java-EE-6-Conversations-Part-4

Sort of

Conversations are named subsections of the session. The name is the conversation id. You call conversation.begin to mark a conversation non-transient. Non-transient conversations have their id:s propagated automagically to the next request and can be resumed. Transient conversations are destroyed at the end of the request

[ifischer]

Thanks for creating the issue! Especially an example in relation to f:ajax would be interesting. I currently also have some problems with Conversations+Ajax+Validation.

So if there are no other tutorials (the one from Reza is good, but there is no source code and no Ajax) i'll post my current issue with Weld&Conversations during the next days. Just hoped i could solve it myself by reading more examples.

[hirowla.ian.rowlands.three.com.au]

Don't know any other tutorials, but I can offer some of my own observations. Most of these are from having breakpoints in my code.

How f:ajax works in relation to backing beans depends on when it is invoked. One observation - every time you do an ajax call or conversation/validation call, a new backing bean is instantiated. At least UNTIL you move to a URL which includes the conversation Id as part of it. After that, you get the same bean (as expected). It's not intuitive but that's what happens and hence you need to code for it. Maybe it depends when you start your conversations. I was trying to only start conversation when I needed one, rather than starting one whether I needed to or not.

The way I think of them is session beans that you manually control - you need to say when you want to start saving them, and stop saving them. And remember to include the IDs in the URLs.

[ifischer]

> every time you do an ajax call or conversation/validation call, a new backing bean is
> instantiated. At least UNTIL you move to a URL which includes the conversation Id as part > of it. After that, you get the same bean (as expected)
Thanks for your comment! This is exactly my current problem, as i didn't move to a new url with the convId. I think that beside an example in the Weld-package, this should be mentioned in the Weld reference.

[ssamayoagt]

See this: http://seamframework.org/Community/ConversationCreatedUntilPOST

Regards.

[infinity2heaven]

I'm looking fwd for a Weld/Conversation/faces-config navigation working tutorial as well. Reza's example is too simple and the seam-javaee-booking in Seam3-beta1 is broken as the conversation use case doesn't work. Is this one of such features that gets crammed into the spec but isn't implemented right?

I remember Seam 2 conversation worked like charm.

[tony.herstell1]

Priya M

> I remember Seam 2 conversation worked like charm.

I so agree...

Use Session scope to collect up the parts that you "might" want to work on, then use conversation scope to work on them...

Keep session stuff updated, using events, and you have reduced your DB access to nothing.

Well explained in the Seam 2 docu-tutorial..

Or Plan B...

Fetch everything again and again and again in Request Scope and limit your scalability massively and also run slowly...

Seam 2 really worked well; shame JEE 6/7 seems to have messed it up.