Menu
▾
▴
springframework-developer
|
From: renaud <re...@ao...> - 2003-11-11 14:19:22
|
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
>
|
|
From: Kopylenko, D. <dko...@ac...> - 2003-11-11 14:51:41
|
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
>
|
|
From: renaud <re...@ao...> - 2003-11-11 15:23:52
|
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 > |
|
From: Rod J. <rod...@in...> - 2003-11-11 17:46:37
|
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 > |
|
From: Rod J. <rod...@in...> - 2003-11-14 16:53:39
|
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 > |
|
From: Colin S. <col...@ex...> - 2003-11-14 17:13:38
|
+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 >>>> >>>> >>>> |
|
From: Rod J. <rod...@in...> - 2003-11-14 22:10:06
|
I'm just making these changes now, although I won't check them in immediately in case there are any objections. It seems that there should be one minor naming change: InterceptionAdvisor --> InterceptionAroundAdvisor It's a bit of a mouthful, but it it is necessary information I think if we're going to accommodate different modes of advice in future. There will be an interface called InterceptionAdvisor, a new superclass that identifies any advisor that works through interception. (Mainly for implementation reasons, rather than for application developers.) My proposal below of making InterceptionAroundAdvisor the superclass of InterceptionAdvisor was questionable because the superclass should have a more specific name. Regards, Rod ----- Original Message ----- From: "Rod Johnson" <rod...@in...> To: <spr...@li...> Cc: "renaud" <re...@ao...>; "Bob Lee" <cra...@cr...> Sent: Friday, November 14, 2003 4:52 PM Subject: Re: [Springframework-developer] AOP API finalization > 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 > > > > > > > ------------------------------------------------------- > 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 > |
|
From: Kopylenko, D. <dko...@ac...> - 2003-11-11 18:51:26
|
Just F.Y.I. jboss-aop uses "Advisor" abstraction, e.g. InstanceAdvisor, ClassAdvisor, ProxyAdvisor Regards, Dmitriy. -----Original Message----- From: Rod Johnson [mailto:rod...@in...] Sent: Tuesday, November 11, 2003 12:36 PM To: spr...@li... Subject: Re: [Springframework-developer] Revised AOP API proposal 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-develop > > er > > > > > > ------------------------------------------------------- > 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 |
|
From: Rod J. <rod...@in...> - 2003-11-12 09:21:19
|
Renaud,
I've add an isPerInstance() method on Advice as you suggested. It's not
currently used by the framework, which relies on the user to configure
appropriately using beans or programmatically. However, I may add some
checks or other support, and it's already available for users to query via
the ProxyConfig API.
Regards,
Rod
----- Original Message -----
From: "renaud" <re...@ao...>
To: <spr...@li...>
Cc: "'Kopylenko, Dmitry'" <dko...@su...>; "'Colin
Sampaleanu'" <col...@ex...>; "'Bob Lee'" <cra...@cr...>
Sent: Tuesday, November 11, 2003 2:18 PM
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
>
|
