As it turns out, there's a problem with 7 below. The key to a ConversationSequenceInterceptor is that the same instance is used for all conversational operations except the ones that end the conversation, with this instance maintaining a flag to determine whether the conversation is starting or not. However, since interceptors are part of a chain, if we try to use a single instance of a given interceptor for more than one operation, we are effectively merging the corresponding chains at the point the interceptor is inserted. In our case, the interceptor is being inserted at the head, so we basically bypass all other interceptors for all chains but the last one. In the sample, one of the operations happens to be one-way but its non-blocking interceptor is being bypassed and so we lose its async behavior. I am checking in a fix that moves the behavior provided by the conversational interceptors (as well as the wire post processor) to the AbstractOutboundInvocationHandler and that disables the wire post processor by removing its entry from core/implementation.scdl.
On 11/27/06, Jim Marino <[EMAIL PROTECTED]> wrote: <snip/>
7. I added two interceptors that will be inserted into invocation chains between conversational implementations. ConversationSequenceInterceptor will be inserted into all operations except ones marked @EndConversation. This interceptor tracks the conversation sequence the operation is invoked in (start or continue). This is necessary so the scope container knows whether to create a new instance or return an existing one (since conversation ids may be reused). Each operation for a wire receives the same instance of the ConversationSequenceInterceptor, which is inserted in the wire post-process phase by ConversationWirePostProcessor. For operations marked with @EndConversation, a ConversationEndInterceptor is inserted.
<snip/>
