A long while back, Tom Elrod proposed a mechanism by which an interceptor stack can be configured for a connection. Someone at a later time suggested that the mechanism should be based on some sort of negotiation. So I've taken these ideas and implemented such a mechanism.

The interceptor stack is negotiated on a per-service basis. The service specifies a list of interceptors at deployment (see org.jboss.cx.remoting.ServiceDeploymentSpec). Each entry in the interceptor list specifies the interceptor name, and a slot number (which is any non-negative integer value). Only one interceptor is allowed per slot. Additionally, each interceptor can be designated as "required", "optional", or "private".

A "required" interceptor means that any client connecting to the service must also support this interceptor. An "optional" interceptor means that the client may opt to enable this interceptor, or it may decline. A "private" interceptor is only set up on the service side.

On the client side, an optional policy callback may be implemented that returns a boolean, which determines whether the client accepts the named interceptor type. If a client doesn't have support for a given interceptor type, a negative reply is assumed.

Once negotiation is complete, the interceptors are added in order by slot number.