Bill got my hear yesterday where he pitched the interceptor design on the 3.0 client side.

Instant love.

We are not that far from it in fact, it a bit of renaming and factory game on the server. Essentially the client does

Generic Proxy -> Handler -> EJB behavior -> Transport

In the transport layer we extract the Tx and Security information.

The pitch was simple it had to do with moving

GP->Handler->interceptor 1 (EJB behavior for example) ->interceptor 2 (Tx extraction) -> interceptor 3 (Security) -> Transport (invoker).

The code is all there and already pluggable I never realized the interceptor pattern was essentially the same as on the server side, well took Rickard to point it out on the server, and bill to point it out on the client.

If someone wants to step up to the plate that would be an awesome little addition.

The application could specify a jboss.xml that describes the client side interceptor like the server side does



<jrmp/iiop>

would be a way to declare a given client (in this case EJB behavior (local calls fielded).

The factorization right behind it is on the server side. Where we expose the "ProxyFactory" (already there in a primitive form) and that PF can export any combination of
(interfaces, stack of client interceptors, transport) and generates the client for it.

This way for ANY MBean SAR that you deploy on the server you can create proxies that exposes a pluggable behavior example you would deploy your SAR and create clients with
<my proxy behavior that I wrote for my client>

<... no tx>


and the connectors on the server side will know to route your message to the right mbean with the right security integration and no tx for example. Voila instant framework distribution.

What is missing here is the location of the objects and the finders for these objects... this is where and EJB like semantic would be handy...

marcf