From BusyConversationException javadoc:

Indicates that the container has rejected a request because a concurrent request is associated with the same conversation context.

The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type BusyConversationException from the restore view phase of the JSF lifecycle.

So I think that AbstractConversationContext.activate() should throw BusyConversationException which should caught, handled and re-thrown in WeldPhaseListener. Something like:

try
{
conversationContext.activate(cid);
}
catch(BusyConversationException bce)
{
conversationContext.deactivate(); // XXX what else here ?
throw bce;
}
}

I'm now throwing BusyConversationException.
I'll think about the XXX and other things we need to handle.

The lock check is in place,
but per-spec behavior will be implemented later.

What about locking first (i.e. testing the failure condition) and then deciding which conversation to activate ?

The attached patch does this but is untested, the naming could be better or we could call activateRequest() from WeldPhaseListener ...

• slightly better naming
• move the non-existent conversation check within conversationContext.activate(cid) where it seems to fit better with the flow

rebase & reformat

Patch #3 applied.