Re: [Springframework-developer] Revised AOP API proposal

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Renaud,

I guess you're right regarding what "advice" should be in AOP. AspectJ is
not the cleanest implementation around.

However, for the moment, I'm going to check in a version with "Advice" as
discussed. (I'm just verifying that the whole test suite runs right now.)

It's fairly easy to refactor to change if necessary later, so we can
continue to discuss this.

I'm not crazy about Advisor. And I suspect that Advice may be clearer to
many, like I, who think of AspectJ concepts.

But let's continue to discuss it, and I'm sure it will be helpful to have
some code out there that implements the basic concepts.

Regarding perInstance, Spring supports this via the BeanFactory's
"singleton/prototype" option or programmatic creation (used a shared
interceptor if you want to). However, I can see that it arguably belongs on
the AOP API.

Spring could probably use a perInstance flag to check that the user has
configured the object correctly, rather than drive the configuration.
However, I'll also leave this out for now pending further discussion.

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
>