Menu
▾
▴
RE: [Springframework-developer] AOP API finalization
|
From: Kopylenko, D. <dko...@ac...> - 2003-11-14 18:38:00
|
+1 for Advice --> Advisor (as I said before) Also, I like the concept of supporting different kinds of Advice (other then interception-around) Regards, Dmitriy. -----Original Message----- From: Colin Sampaleanu [mailto:col...@ex...] Sent: Friday, November 14, 2003 12:14 PM To: spr...@li... Subject: Re: [Springframework-developer] AOP API finalization +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 >>>> >>>> >>>> ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
