[Springframework-developer] Re: Re: AOP API proposal

[roger h. <apo...@sn...>]

Rod

Let me try and explain myself more clearly - ever hopeful...

> Are "implemented" interfaces the present getIntroducedInterfaces()?
yes.

The 'declared' interface would be a single interface for which an
introduction interceptor contracts to provide an implementation.  The
'implemented' interfaces would be the full set of superinterfaces for  the
'declared' one.

What I am after is the mechanism for an IntroductionAdvice and an
IntroductionInterceptor to be able to specify a set of requested interfaces,
by referring to a single type name - this being the 'declared' type - for
which the introduction contracts to supply the implementation.

The point being that many IntroductionInterceptors may have many
'implemented' interfaces in common - in my previous example InterceptorOne
and IntercptorTwo both implemented interfaces Ia and Ib.  So by forcing an
IntroductionInterceptor to provide a single 'declared' interface type, that
collects all the interfaces that it actually implements, I am now able to
use that 'single type name', as a selector for an actual instance of an
IntroductionInterceptor - ie i can ask a factory for an interceptor that
declares it will deliver an implementation for the collection of interfaces
named Ib, or Ic, rather than asking for something that can deliver a pair of
super interfaces Ia and Ib, which in this example is actually still an
ambiguous request.

In short, I want to be able to use the name of a single declared 'interface'
to refer to the particular collection of interfaces that is actually being
implemented.  For this to happen, the IntroductionInterceptor needs to state
what the 'declared' interface is, and the IntroductionAdvice can then refer
to it.

The sort of use case I have in mind is as follows.  If the
IntroductionAdvice were to specify a 'declared' interface, but not an
IntroductionInterceptor, then a bean factory could check whether an
IntroductionFactoryBean was available to match this 'declared' interface
name.  If so, then the corresponding IntroductionInterceptor could be
retrieved from the factory bean, and we are in business - we are wiring up
an interceptor chain by suppling requests for 'named interface types', as
opposed to the current 'named interceptors'.  Of course, the binding of the
IntroductionFactoryBeans, or the IntroductionInterceptors to the interface
names can be externalised into the bean config file, as usual.

The larger picture is about being able to use the interface names to wire up
the Proxy beans, as well as the interceptor names.

Is this any clearer ?

> 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.

Could you please elaborate on this example - it might help to clarify my
understanding of the use cases you envisage ?  In particular I don't
understand what you mean by interfaces specified in the advice, not in the
interceptor ?   I was imagining that the Advice was declaring precisely the
interfaces that the interceptor should deliver - the point of discussion
being just how these were being named - if it is otherwise - how does it
work - I am definitely gapping, as the americans would say ;)

Have you committed a copy of the code yet - maybe looking at that would help
me understand better ?

Thanks for your patience

Roger


"Rod Johnson" <rod...@in...> wrote in message
news:213d01c3a6d6$8a7fcf70$3800a8c0@chopin...
> 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
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/