|
From: Rod J. <rod...@in...> - 2003-11-09 15:31:43
|
Roger,
I'm still not entirely sure I understand what you're driving at.
I think the problem is that I don't quite get the distinction between
"declared" and "implemented" interfaces.
Are declared interfaces those that the IntroductionInterceptor really
implements. (E.g. the case when the DelegatingIntroductionInterceptor uses
itself as delegate?) In that case, can't they be queried using
introspection?
Are "implemented" interfaces the present getIntroducedInterfaces()?
> When defining an IntroductionAdvice and an IntroductionInterceptor, how
> about the use of a single Declared Interface, rather than a list of
> Implemented Interfaces, ie:
>
> public interface IntroductionAdvice extends Advice {
>
> IntroductionInterceptor getIntroductionInterceptor();
>
> Class getInterface(); // single declared interface
>
> }
>
> public IntroductionInterceptor extends Interceptor {
>
> Class getDeclaredInterface(); // single declared interface
>
> Class[] getIntroducedInterfaces() // as at present
>
> }
I think there are occasions when we might want to introduce multiple
interfaces, or (in odd cases) interfaces specified in the advice, not the
interceptor. To take a rather contrived example, I might have a
RemoteException interceptor that throws RemoteException on every method call
if the signature has "throws RemoteException", for use in a test
environment. I could introduce this with an advice specifying that the
introduced interfaces should be MyRemoteEjbBusinessInterface, which the
generic test RemoteExceptionIntroductionInterceptor has never heard of.
Would it be possible to do what you want with an abstract implementation of
IntroductionInterceptor (probably a subclass of
DelegatingIntroductionInterceptor), rather than with the core interfaces?
This could enforce a single introduced class and provide a method returning
it.
Regards,
Rod
|