Applying server-side interceptors to JRMPProxyFactory

[dimitris]

This is really about detached invokers.

In the JRMPProxyFactory we can specify client-side interceptors that are configured inside the exported client-side proxy.

Now, when the JRMPProxyFactory is configured with "InvokeTargetMethod=false", the call is forwarded to the target mbean that must expose/implement the signature:

public Object invoke(org.jboss.invocation.Invocation invocation) throws Exception.

In this manner the target mbean has access directly (or through an xmbean interceptor) to the Invocation object sent from the client side, that may include piggybacked data stored there by the client-side interceptors.

However, when the JRMPProxyFactory is configured with "InvokeTargetMethod=true", the call is forwarded to a specific target mbean method (e.g. do()) rather than the generic invoke() method. This is very convenient when remoting an MBean but in this case we loose the Invocation context.

What would be the best way to apply server-side interceptors with access to the original Invocation context?

Have a second server-side interceptor stack on the JRMPProxyFactory?

[starksm64]

This is something we will address in the new microcontainer with a unified container/aspect framework. I don't see us introducing yet another layer into the current frameworks. We need to get the microcontainer done and at that point look at ebedding it as a framework for use in 4.x that allows consistent programming between 5.x, ejb3, and aop.