For the most part I can't see much point declaring a bean as ConversationScoped if you're not going to use it in a long running conversation. Otherwise a transient conversation is just a pseudo-request scope. Secondly if I've declared the class ConversationScoped why start a long running conversation in one method and not another? The only use-case I can think of is a conversation bean as a producer which can produce without a long running conversation (why not use a dependent scoped bean anyway!). Can anyone else think of a good use case for transient conversations?
Anyway in most of my use cases of a ConversationScoped bean I want to do something like this:
@Named
@ConversationScoped
@LongRunning(REQUIRES_NEW)
public class MyBean {
.
.
.
}
The possible states are:
JOIN_EXISTING
Joins an existing long running conversation if it exists otherwise throws an exception
JOIN (the default)
Joins an existing long running conversation or promotes the current transient conversation to a new long running conversation.
REQUIRES_NEW
Always starts a new long running conversation even if one already exists
REPLACE
Ends any existing long running conversation and creates an new long running conversation. This is use full if you want to enforce one conversation at-a-time.
The first two items can be done using a standard interceptor. To do the last two items you really need to create a custom implementation of the conversation scope because by the time it is intercepted it is already in a conversation (albeit a transient one sometimes). Perhaps there is a better way that I haven't thought of?
Ideally then I like to see:
@Named
@Conversational(REQUIRES_NEW)
public class MyBean {
.
.
.
}
Rather than overriding ConversationScoped and adding the demarcation attributes which could cause confusion I thought Conversational might tell the right story.
I'd love to hear feedback on this.
