Re: [Springframework-developer] AOP API - How to keep a ProxyConfig honest ?

[Rod J. <rod...@in...>]

Roger,

> The ProxyConfig interface allows for the adding / removing of Interceptors
&
> Advice - but nothing to support the changing of the Interfaces being
> proxied.  At first I thought this was a lack, but then I realised that
since
> any interface is logically associated with an interceptor that will handle
> the calls on it, this is entirely reasonable.  The only problem at
present,
> is the way that ProxyConfigSupport deals with the interfaces - basically
> they are not all attributable to their respective interceptors - so if
> someone happens to remove, or change the ProxyInterceptor, we're out of
> luck.

I think your suggestion has merit, although I think it's unlikely to make
M3. I don't think it has to break APIs, so I think we could possibly add an
Advice (Advisor) such as you describe below subsequently.

> After more pondering it seems to me that one solution would be to add a
> further Advice - ie one that does for invoking interceptors, what
> IntroductionAdvice does for IntroductionInterceptors.  For arguments sake
> I'll call it an InvokingAdvice, eg:

This does make sense. Adding a ProxyInterceptor could be a shorthand, just
like adding an Interceptor is a shorthand for adding an Advisor that matches
all method invocations.

I have some questions about the interface below, although I think the
concept is good:

> public interface InvokingAdvice extends Advice {
>
>  ClassFilter getClassFilter();
>
>  Interceptor getInterceptor();
>
>  Class[] getInterfaces();
>
> }

Why would an interceptor be needed at all? The call to proceed() is
potentially misleading? What about just having a target object or an
implementation of an invoke(Method, args) method?

What does ClassFilter do here?

This could also possibly be another way to do introductions.

> With the use of an InvokingAdvice, it becomes possible to require that all
> Interfaces passed into ProxyConfigSupport are duly packaged in an
> appropriate Advice / Interceptor pair.  The only problem, is that lots of
> existing code expects to be able to pass in just an InvokerInterceptor...

But that should still work as a shorthand perhaps.

> In the case of Introductions, the present strategy for dealing with
> Interceptors that are received by ProxyConfigSupport without an enclosing
> Advice, is just to throw a config exception.  However, I think there is
> actually sufficient information available to be able to build an enclosing
> Advice dynamically - ie. the call to ProxyConfigSupport.setInterfaces()
has
> supplied a set of candidates interfaces, and the IntroductionInterceptor
> provides an implementsInterface() call that can be used to test these for
> eligibility.
Fair point.

>
> The same stretegy can also be employed for InvokerInterceptors, since each
> comes together with its target that can be used to test for eligibility.
> This would leave outstanding. only those interceptors that neither
implement
> IntroductionInterceptor nor ProxyInterceptor - for these cases, calls to
> ProxyFactory.addInterceptor() would still need to be changed to
> ProxyFactory.addAdvice().   (By inspection, I think these cases include
code
> in about 4 core classes and their corresponding test cases)

Regards,
Rod