RE: [Springframework-developer] Revised AOP API proposal

[renaud <re...@ao...>]

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
>