Re: [Springframework-developer] AOP API finalization

[Colin S. <col...@ex...>]

+1  - This all sounds reasonable to me.

Rod Johnson wrote:

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