Re: [Springframework-developer] AOP API finalization

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

All,

Let me begin with an apology for those of you who may be getting a bit bored
with arcane debates about AOP... Spring will continue to provide declarative
transaction management in the present simple way, without the need to work
with the AOP interfaces and framework directly. And we will provide even
easier .NET style automatic "enterprise services" for transactions etc. in
the future. So most users likely won't need to work with this lower level
stuff. However, it's still important to get it right.

Now the AOP code is committed and no one has screamed about it (which I take
to mean that everyone who's interested agrees it's on the right track :-), I
think the hard work has been done. What I'm talking about there is
essentially minor refactoring that doesn't change the way things work.

However, I think there are a few things still to do before we go to final:

1. I think Renaud is right regarding Advice --> Advisor. (See the rest of
this email for the discussion.) So I propose that we rename anything with
the suffix Advice to Advisor. (Affects interfaces and advice superclasses.)

PLEASE feedback your views on this--particularly, if you object strongly.

2. I think it's important that we're not tied into interception.
Interception is one way of implementing around advice. However, it's been
taken in Nanning, Spring and JBoss as being "the way to do AOP." Around
advice is not always the best programming model for application developers,
as Gregor points out. Pre and Post advice is also important, and we should
be able to support that as well. It may be possible to implement more
efficiently than intercepted around advice, also. E.g. it doesn't require an
interceptor chain: ie there's no need for a MethodInvocation object because
there's no need to have a "proceed" concept (the advice doesn't take control
and get to decide whether to proceed to the joinpoint.)

We should also be able to support any kind of advice: e.g. "call an
arbitrary method via reflection before this method." (Of course the
arbitrary code wouldn't have knowledge of the joinpoint, but that mightn't
matter in situations where the pointcut was sufficient to determine whether
something should happen or not.)

I think we're a lot of the way towards generalizing the API support in
Spring but we still need to go a bit farther:

a. IntroductionAdvice --> InterceptionIntroductionAdvisor (to allow the
possibility of introduction other than by interception around advice)

b. Possible new superinterface InterceptionAroundAdvisor for
InterceptionAdvisor and InterceptionIntroductionAdvisor. This wouldn't be
used by end users, so might be added at any time to help the implementation
be more efficient.

These small changes now could allow different types of advice and additional
implementation strategies in the future, in a backward compatible way.

Regards,
Rod

----- Original Message ----- 
From: "renaud" <re...@ao...>
To: <spr...@li...>
Cc: "'Colin Sampaleanu'" <col...@ex...>; "'Bob Lee'"
<cra...@cr...>
Sent: Tuesday, November 11, 2003 3:23 PM
Subject: RE: [Springframework-developer] Revised AOP API proposal

>
>
> Yes. Actually I do not like the fact that in AspectJ an advice in defined
> regarding a pointcut.
> I've found it very unclear what is exactly the advice in the AspectJ
> semantics.
>
> <AspectJDoc>
> A join point is a well-defined point in the program flow. Pointcuts select
> certain join points and values at those points. Advice defines code that
is
> executed when a pointcut is reached. These are, then, the dynamic parts of
> AspectJ.
> </AspectJDoc>
>
> By reading this, you can really think that the advice and the pointcut are
> orthogonal and defined independently. Indeed, it seems not flexible at all
> to define at the same place the code to be executed and where it is
> executed.
>
> But, later in the same doc:
>
> <AspectJDoc>
> Pointcuts are used in the definition of advice.
> </AspectJDoc>
>
> To me it is confusing. Moreover, lots of work on AOP have pointed out the
> benefits of having independent structures for the both. To me AspectJ
misses
> something here: the ability to define independent (unlocated) advice -- 
like
> an interceptor does.
>
> So it seems to me that the concept of Advisor helps here. It sounds like
> saying "we advise some code" and "we do not use advice concept
specifically
> because it is unclear and, btw, we use interceptors which are independent
> structures - more flexible than the advice constructs in AspectJ".
>
> Regards,
> Renaud.
>
> ---
> Renaud Pawlak
> Software Engineering Department
> Rensselaer at Hartford
> 275 Windsor St, Hartford, CT 06120-2991
> Work: 860-548-5358 Mobile: 860-748-5527
> Emails: pa...@rh..., re...@ao...
> WWW: http://www.lifl.fr/~pawlak
>
>
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]
> >  On Behalf Of Kopylenko, Dmitry
> > Sent: Tuesday, November 11, 2003 9:52 AM
> > To: 'renaud'; 'spr...@li...'
> > Cc: 'Colin Sampaleanu'; 'Bob Lee'
> > Subject: RE: [Springframework-developer] Revised AOP API proposal
> >
> >
> > Advisor does not fall under "standard" AOP concepts as
> > opposed to Advice, but I like the name better.
> >
> > My 2c.
> >
> > Dmitriy.
> >
> > -----Original Message-----
> > From: renaud [mailto:re...@ao...]
> > Sent: Tuesday, November 11, 2003 9:19 AM
> > To: spr...@li...
> > Cc: 'Kopylenko, Dmitry'; 'Colin Sampaleanu'; 'Bob Lee'
> > Subject: RE: [Springframework-developer] Revised AOP API proposal
> >
> >
> >
> > Hi all,
> >
> > I have been working a lot these last days on a JAC
> > refactoring in order that our two frameworks implement a
> > simplar API (well, as much as possible). Morever this allows
> > me to detect weaknesses of the proposed API.
> >
> > Rod, when do you plan to consider the API definitively fixed
> > (so that I kown until when I can work on it)?
> >
> > The main problem I see for now on is about the per-instance
> > property. In AOP, you are supposed to be able to precise if
> > the aspect will be applied globally, or on a per-instance
> > basis. For instance, you may want an advice to install the
> > same interceptor for your whole pointcut, or seamlessly
> > create a different instance for each instance cut by the pointcut.
> >
> > This is not difficult to solve. We can propose a method
> > isPerInstance() on the Advice.
> >
> > By the way, by thinking a lot about this "Advice" interface,
> > it turned out that the concept of advice as defined in AOP (I
> > means theorical AOP) does not includes the pointcut. However,
> > in AspectJ, it actually corresponds to an actual construct.
> > So, I figured out that the best way to solve the issue was to
> > call this construct an "Advisor". Note that it has the
> > advantage to solve the problem of the advice plural
> > ("Advice[] getAdvice()" is not very cool).
> >
> > So my intermediate proposal would be:
> >
> > public interface Advisor {
> >     boolean isPerInstance();
> > }
> >
> > And rename
> > InterceptionAdvice into InterceptionAdvisor
> > IntroductionAdvice into IntroductionAdvisor
> >
> > In the aspect, you will also have a getAdvisors method
> > instead of a getAdvice method.
> >
> > As you can see, it is not a big deal of a change at all.
> >
> > Best,
> > Renaud.
> >
> > ---
> > Renaud Pawlak
> > Software Engineering Department
> > Rensselaer at Hartford
> > 275 Windsor St, Hartford, CT 06120-2991
> > Work: 860-548-5358 Mobile: 860-748-5527
> > Emails: pa...@rh..., re...@ao...
> > WWW: http://www.lifl.fr/~pawlak
> >
> >
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...]
> > >  On Behalf Of Rod Johnson
> > > Sent: Monday, November 10, 2003 12:35 PM
> > > To: spr...@li...
> > > Cc: renaud; Kopylenko, Dmitry; Colin Sampaleanu; Bob Lee
> > > Subject: [Springframework-developer] Revised AOP API proposal
> > >
> > >
> > > All,
> > >
> > > Here's a variant on the API API which goes down the path initially
> > > suggested by Renaud with separate class and method
> > designators. Apart
> > > from that it's much the same: Advice is still almost the same.
> > >
> > > The unit of composition is a ClassFilter or MethodMatcher. The new
> > > Pointcut interface allows for FieldMatchers in the future.
> > >
> > > Abstract convenience classes could make it easy to use: for
> > example,
> > > the RegexpPointcut could continue to implement Pointcut,
> > with no need
> > > for the application developer to work with a distinct
> > ClassFilter or
> > > MethodMatcher. I think the only downside of this proposal
> > is ease of
> > > use, and convenience classes can resolve that.
> > >
> > > This also enables IntroductionAdvice to have only a ClassFilter, as
> > > Bob wanted.
> > >
> > > Static methods are still used to "compose" pointcuts and the
> > > finer-grained units of composition.
> > >
> > > Feedback please... This is an important API to get right,
> > and time is
> > > closing now, as we don't want this to delay M3.
> > >
> > > 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/
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
> -------------------------------------------------------
> 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/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>