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

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

Rod

"Rod Johnson" <rod...@in...> wrote in message
news:30b801c3ac86$99bf92d0$3800a8c0@chopin...
> 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:

As much as anything, I chose the interface as the quickest way to
illustrate the concept.  I was not, and still am not, clear in my own mind
about what it actually needs to be.  I'll try to answer your questions &
outline further thoughts below...

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

In the general case, ie outside of intercepted around advice, there is
clearly no need for an interceptor.

Not sure about your reference to proceed().  Within the current code, where
all advice is actually implemented as intercepted around advice, the one
thing that distinguishes Introduction interceptors and Invoking
interceptors, is that they break the interception call chain, ie. within
MethodInterceptor.invoke(), they return the result of

    invocation.getMethod.invoke()

rather than, as the straight Method interceptors do, returning the result
from the next interceptor, ie

    invocation.proceed()

In other words, the one thing that Introduction and Invoking interceptors do
'not' do, is call proceed().

> What does ClassFilter do here?

Not sure how useful this might be - in the abstract it would enable an
InvokingAdvice to declare the notion that these interfaces can be used to
filter calls on any classes that match this ClassFilter.  I guess that when
building the interceptor chains, there would need to be a check that the
target classes did actually implement the named interfaces, possibly
throwing a config exception if not.

> This could also possibly be another way to do introductions.

Possibly - I guess the difference that's implied in what I've described
above, is that Introductions define a set of 'additional' new interfaces to
be added to any matching classes, whereas Invokers would define a set of
'restricted' interfaces that may be exposed, but that are expected to be
already present on any matching classes.

Perhaps it's useful to recast some of this using the more recent
Interception and Advisor nomenclature, since this helps to eliminate stray
references to interceptors ;)

For the sake of discussion, how about the following:

public interface InvokingAdvisor extends Advisor {

    ClassFilter getClassFilter();

    Class[] getInterfaces();

}

public interface InterceptionInvokingAdvisor extends
                          InterceptionAdvisor, InvokingAdvisor {

    Interceptor getInterceptor()

}

Most of these Invoking interceptors will typically implement
ProxyInterceptor, so maybe this method should be:

    ProxyInterceptor getProxyInterceptor()

I guess the key question is whether its possible to conceive of one that
wouldn't ?

Within the current code base, the non-conformists include:

RmiClientInterceptor
BurlapClientInterceptor
HessianClientInterceptor
LocalSlsbInvokerInterceptor
SimpleRemoteSlsbInvokerInterceptor

In practice, each of these does actually construct a target and thereby
implicitly implement ProxyInterceptor - although the
SlsbInvokerInterceptors, don't construct their target session bean instances
until their invoke() methods are called.  In itself, this is not a problem,
as long as the enclosing StatelessSessionProxyFactoryBeans remember to
create an InvokingAdvice that explicitly declares the business interface.

And for Introductions:

public interface IntroductionAdvisor extends Advisor {

    ClassFilter getClassFilter();

    Class[] getInterfaces();

}

public interface InterceptionIntroductionAdvisor extends
                          InterceptionAdvisor,
                          IntroductionAdvisor {

    IntroductionInterceptor getIntroductionInterceptor();

}

That's about all I can think of for the moment.

Does this help ?

Roger


>
> > 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
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl