There's currently no support for conversation scope in SE. The reason for this is that the definition of a conversation tends to be application specific for SE apps.
That said, I would like to at some point provide the infrastructure for a conversation context, along with a simple API that application developers can use to manage conversations in a way that makes sense for their application.
Also can I ask out of curiosity, what behaviour in your application requires conversations?
For now I actually do not need need a conversation context as I am getting by using the Application scope. However it is such a natural concept to help organize code that it would be really nice if you can get it going.
If conversation scope was available I probably would have tried using that instead so here goes a description of the problem.
Periodically the application needs to do a heavy computational job. This main job gets split into smaller jobs and farmed out via jms to job consumers who send the results back via jms. The results then get collected in the Application scope. I was originally thinking performing the main job in a conversation scope. Each main computation being a conversation with the result collated in the conversation scope.
This way the main app can run multiple heavy computations simultaneously, each in its own conversation. As I understand it thread scope will not work as the result are coming back via jms in different threads.
The idea of a conversation is typically multiple HTTP request/response cycles (in a web app). Conversations are aggressively managed in the user's HttpSession. I don't see why it has to be limited to a web app scenario.
In VB and Powerbuilder apps (client/server days 80s-90s), there were use cases that could indeed be modeled as LRCs or wizards (all it really amounts to is multiple screens or multiple tabs, right?) I don't think the number of tiers in the platform/technology would dictate whether a conversation is permissable or not.
But what is the session in a SE app? Not HttpSession so then after user authenticates until user logs off? Where would all the LRCs be stored in the SE scenario?
I think business process scope or thread scope make more sense in a SE app. Conversation scope is designed for a web environment, I don't think the concept directly maps to a SE app.
maybe you're right but that's like saying there are never conversations in a Swing app (client/server). Is that always the case?
btw, what is thread scope? never heard of that before.
I guess the issue is that SE apps don't have an HttpSession object like javax.servlet.http.HttpSession interface. So where would the conversations live in a SE app?
I found out about it via google. There is code in trunk for it but is not quite fully functional yet I think. Seems very nice tho and exactly what we need in many of our app at my current company who are big into starting loads of threads all the time.
Good find Pieter. Yes the code for @ThreadScoped is there and just needs re-enabling now that a bug in core has been fixed. That's on my list of things to procrastinate on.
Regarding ConversationScoped, lets talk about the two scenarios - server side and client side.
Request, session and conversation scopes make sense in Java server-side apps which are written in non-EE technologies. For example imagine using Weld SE like you would have once used Spring to wire together many non-EE frameworks/COTS products into a custom Frankenstack. You'll still want to route multiple concurrent incoming requests into sessions and possibly conversations.
In fact, even something like a FIX protocol 'front-end' plugged into a Java EE backend would need some kind of non-HTTP-specific concept of sessions, requests and conversations.
But then there's the client-side, and this is where I don't think conversation scope fits in at all. A DepenantScoped bean with a conversationId is all you would need for a tab within a thin-client to participate in a server-side conversation.
Does that make sense?
...also, @ThreadScoped is back in trunk.
Yeah, I agree, the client simply participates in server side conversations. That said however in SE apps the distinction between client and server becomes rather blurred. I also think that perhaps we should not think of clients in terms of tabs as clients need not particularly be human actors participating in a conversation.
My 5 cents...