Fw: [Springframework-developer] Re: AOP API

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

From an earlier exchange we really should have sent to the list...

>> = Bob
> = Rod
----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: "Bob Lee" <cra...@cr...>
Cc: "renaud" <re...@ao...>
Sent: Saturday, November 08, 2003 5:23 PM
Subject: Re: [Springframework-developer] Re: AOP API


> Bob,
>
> > 1) The introduction interceptor implementation and what interfaces it
> > should implement should be separate, hence IntroductionAdvice. Perhaps
> > your interceptor could implement any interfaces. Or, the user may just
> > want to use a subset of the interfaces you can handle. The point is
> > that this logic doesn't need to be built into your interceptor
> > implementation (as it is in IntroductionInterceptor).
>
> Yes, I understand what you mean now. I think you're right.
>
> > 2) The AspectJ terminology kind of smells to me. It was very daunting
> > when I was first exposed to it. "Pointcut, WTF?" Also, I fear that the
> > use of the terminology is imposing AspectJ's design on our own. I know
> > for a fact no one else on my team has any idea what a "pointcut" is.
> > Perhaps "mapper" or "query" would be a better term. My thought is that
> > "mapping servlet filters" or the "query pattern" (PoEAA) may be more
> > familiar concepts than AspectJ.  Do you see this as an issue?
>
> I don't think it's very intuitive terminology either. But I think the
> industry is stuck with it. I think it would be a mistake to reinvent it at
> this stage.
>
> > 3) I don't know about the inheritance scheme with the
> > pointcuts/designators below. My goal is to be able to use any method
> > pointcuts with any class pointcuts. If the method pointcut inherits
> > class pointcut functionality, it makes this more difficult.
> > I also want to be able to combine pointcuts. For example, I'd have an
> > AndClassPointcut that would take two other class pointcuts. I could use
> > one to match a package name and another to determine instanceof.
>
> I agree combinations of pointcuts are useful. I envisaged having a static
> convenience methods for this like
>
> static Pointcut and(Pointcut a, Pointcut b);
>
> To me there should be a single pointcut object (however it's created) that
> can tell me all I need to know about which joinpoints a piece of advice
> should apply to.
>
>
> > 4) I really like that you can implement introductions using an
> > interceptor (I felt weird about it at first). This makes lazy-loading,
> > etc. very clean.
> >
> > What I don't like about the current design is
> > IntroductionInterceptor.getIntroducedInterfaces(). I guess it's because
> > the ProxyFactory has special knowledge of this one subinterface and it
> > magically adds the interfaces.
>
> Yes, I have always been a little uncomfortable with this. So you suggest
> moving the magic to an Advice class, which would still need to be treated
> specially? I do take the argument that a specific advice might only use
that
> interceptor to expose a subset of the possible interfaces it could
support.
> Also that one could implement _any_ interface, although that mightn't
> coexist happily with interceptors further down the chain :-)
>
> Perhaps there's still an argument for a getSupportedInterfaces() method on
> an IntroductionInterceptor interface to enable it to ensure correct usage.
> Otherwise, what's to tell someone that they've added an introduction for
> Foobar interface with a SomethingElseInterceptor that won't help to
> implement Foobar? There would be a no such method error if the invocation
> ever got to a target.
>
> > This is one of the reasons for the separate InterceptionAdvice and
> > IntroductionAdvice, the other being that IntroductionAdvice needs a
> > class designator and InterceptionAdvice needs both class and method
> > designators.
> >
> > 5) I think we should remove AttributeRegistry. The JSR is finalized now
> > and I don't think we need to worry about abstracting attributes in
> > aopalliance. Also, passing it to the pointcut shouldn't be necessary.
>
> I guess this is a fair point. We are planning to provide a metadata
> abstraction in Spring. I'm not convinced that JSR-175 is the whole
metadata
> solution because there's just one source of metadata--the class file (via
> the reflection API). It's nice to be able to override some metadata at
> deploy time if necessary. Also, how long before we get to see 1.5 and how
> long before we get to use it on real projects?
>
> However, I guess there's an argument for moving the metadata stuff down to
> interceptor level, since no one else has ever really believed it should be
> in AOP Alliance. Renaud, what do you think?
>
> > 6) I need a generic factory that I can pass any object to and get the
> > proxied version back. Is this where the BeanPostProcessor comes in? I
> > see myself using the new pointcuts to map the interceptors to these
> > objects.
>
> A BeanPostProcessor registered with a bean factory can automatically proxy
> any object it wants. Configuring this stuff could be pretty cool with the
> post processor: just include Advice objects in the bean factory and a
> modification of an existing post processor for the new API could create
> proxies as necessary for objects affected by the advice.
>
> Regards,
> Rod
>