> I think maybe we need to not think of the client
> stack and the server stack as one aspect but rather
> as 2 different aspects.

Yes.. They are 2 different aspects. And the types of interceptors you place on those aspects are different (you can allow serverside interceptors to have access to the JMX bus).

>
> The Client aspect is an aspect with no target object.
> Just an interceptor on the end that makes an
> invocation on a remote Invoker.
>

I can agree on that.. Then I think we need to add another create method to the AspectFactory which accepts the following args: (String aspectName, Class []targetInterfaces).
This is so that the proxy object also exposes the targetInterfaces even though it has a null targetObject.

Or Perhaps we can use the targetObject as our key to lookup the right serverside aspect???

> The Invoker takes the invocation and invokes on an
> MBean. The MBean itself is an Aspect and this is
> where the server interceptors live.
>

We should also try to decouple the server-side aspects from JMX as much as possible. The Factory or Deployer that creates the server-side aspect should be the one that registers the aspect in JMX. Use some reflection technique to implement the MBean for the aspect (perhaps even implement it via another aspect).

If we we can do this, then we have a chance at allowing applications to creating a WHOLE container stack via an aspect definition. (They would just need another set of Factories that did not use JMX). Some applications don't NEED JMX managment.

> Now, when the server needs to change the interceptor
> chain on the client, the Invoker throws an exception
> with the new interceptor stack embedded in the
> exception. (Much like a LocationForward in CORBA.).
> The Client aspect catches this exception, recreates
> the interceptor stack and re-invokes the method
> call.
>

Ok.. I can buy this but I don't think this applies at the generic aspect level. This needs to just be at the invoker level. The last interceptor in the client aspect will be the invoker client. That interceptor will need the abililty to chanage the aspect definition for the proxy.

> All in all I think it is very important to have an
> InvocationResponse object as Adrian talked about.
> I've been meaning to put this in for a long time.
>
> Bill

> > Now, when the server needs to change the
> interceptor
> > chain on the client, the Invoker throws an
> exception
> > with the new interceptor stack embedded in the
> > exception. (Much like a LocationForward in
> CORBA.).
> > The Client aspect catches this exception,
> recreates
> > the interceptor stack and re-invokes the method
> > call.
> >
>
> Ok.. I can buy this but I don't think this applies
> at the generic aspect level. This needs to just be
> at the invoker level. The last interceptor in the
> client aspect will be the invoker client. That
> interceptor will need the abililty to chanage the
> aspect definition for the proxy.
>

I agree with that. An InvocationResponse should not be
used in the base invocation chain as the return value.

But the invocation handler needs some way of knowing
to retry the invocation with the new chain.
And other client/server interceptors need some way of
using it as well.

My preferred solution is to allow an
optional InvocationResponse object in the invocation.
The invokers would be responsible for returning it
to the client and updating the client's copy of the
invocation with any response object.
For local invocation, no work is required.

This would allow things like Marc's invocation level
logging where the client can retrieve all the server
logging for an invocation.

Regards,
Adrian

> > Ok.. I can buy this but I don't think this
> applies
> > at the generic aspect level. This needs to just
> be
> > at the invoker level. The last interceptor in the
> > client aspect will be the invoker client. That
> > interceptor will need the abililty to chanage the
> > aspect definition for the proxy.
> >
>
> I agree with that. An InvocationResponse should not
> be
> used in the base invocation chain as the return
> value.
>

cool.

> But the invocation handler needs some way of knowing
> to retry the invocation with the new chain.

Perhaps the invoker needs to throw a special "retry exception" which the IH catches and does a retry???

> And other client/server interceptors need some way
> of
> using it as well.
>
> My preferred solution is to allow an
> optional InvocationResponse object in the
> invocation.
> The invokers would be responsible for returning it
> to the client and updating the client's copy of the
> invocation with any response object.
> For local invocation, no work is required.
>
> This would allow things like Marc's invocation level
> logging where the client can retrieve all the server
> logging for an invocation.

I like this. Make it more generic. Have a Map that holds response objects. client side interceptors could communicate server side interceptors with every method call by placing objects in request and response maps.

How expensive is it to create a new Map for each method call??

Regards,
Hiram

>
> Regards,
> Adrian

Maps are expensive.

It isn't the actual Map, more all the Map.Entry objects
that have to be constructed.

Regards,
Adrian