The specification mentions @Conversational and @Scope(Conversation) but
there is no clarification how these interfere together and what should
happen in all the possible combinations.
Two new paragraphs should be added in section (3.2 @Conversational) that
have the following wording :
In case an interface is marked as conversational but the scope of the
target implementation is different than @Scope(Conversation), than the
SCA runtime would invoke an instance as defined by the scope. In case
the scope is the default one (stateless) than the container may dispatch
to a new instance each time or alternatively pull one from a pool. In
this case, it is assumed that the implementation itself will manage
state. The implementation would be responsible for using the
conversation id associated with the request (obtaining it through
injection or via the SCA API) to obtain state stored somewhere (cache ,
database , etc.).
In case the target implementation has @Scope(Conversation) and the
interface is NOT marked as conversational than there will be no
conversation, attempts to retrieve conversationId will result in null,
and the SCA runtime may behave as if for that particular invocation the
scope has been defined as stateless.