RE: [Springframework-developer] AOP API

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I think that nobody has already implemented the org.aopalliance.aop.Aspect
interface because its goals are not very clearly defined. Having a
standardization effort is a good but difficult thing because we should agree
on what we want to standardize, but also on the goals of the
standardization. Indeed, implementing common interfaces will not
automaically make two frameworks compatible. For example, JAC and Spring
both implement the org.aopalliance.intercept interface. This does not make
Spring and JAC more compatible because their implementations diverge very
fast.

I am currently investigating the possibility to reshape the AOP Alliance
goals, strategy, and environment so that it becomes better defined and, if
possible, funded with academics projects. So I do not think that Spring
should absolutly try to implement all the AOP Alliance interfaces for the
moment, but just tend towards the better and more generic solution.

So, +1 for pointcut-interceptor paris... oops, pairs :-)

PS: I am currently just starting to take a closer look at the Spring API.
I'll know more in a few days and I will be able to better participate.

---
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: Friday, November 07, 2003 9:01 AM
> To: 'spr...@li...'
> Subject: RE: [Springframework-developer] AOP API
> 
> 
> So,
> 
> Could we rework org.aopalliance.aop.Aspect interface or we 
> should stick with Spring one? Has anyone implemented 
> org.aopalliance.aop package yet?
> 
> Dmitriy.
> 
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...] 
> Sent: Friday, November 07, 2003 8:52 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] AOP API
> 
> 
> Comments from Renaud Pawlak (JAC, AOP Alliance) on the 
> proposed change:
> 
> > Btw, I'm considering changing the Spring AOP API so that 
> there's a new
> > type, Aspect, that will contain both a Pointcut and an Interceptor. 
> > This way pointcuts can be reused. What's your view on that?
> 
> <renaud>
> I agree because an aspect component in JAC would correspond 
> to this. However, an aspect should be able to contain a set 
> of pointcut-interceptor pairs rather than ony one. Indeed, in 
> the general case, a crosscutting concern is not about 
> modularizing only one piece of advice but several ones 
> related to the same concern (e.g. authentication). Having 
> only one interceptor per aspect would be a little bit like 
> authorizing only one method per object in OOP... </renaud>
> 
> I think this is a good point. A convenience implementation of 
> Aspect could take care of the common "single interceptor and 
> pointcut" case avoiding complicating typical usage.
> 
> Regards,
> Rod
> 
> ----- Original Message ----- 
> From: "Kopylenko, Dmitry" <dko...@su...>
> To: <spr...@li...>
> Sent: Friday, November 07, 2003 1:27 PM
> Subject: RE: [Springframework-developer] AOP API
> 
> 
> > Rod,
> >
> > Funny you should mention that, but I was thinking along the 
> same lines
> > a
> few
> > days ago :-) Aspect would represent the right level of 
> abstraction as
> > Interceptors and Pointcuts are just "implementation 
> instruments" of it 
> > (certain Aspect). I was thinking to utilize (somehow) existing 
> > org.aopalliance.aop.Aspect but the current API wouldn't fit 
> the model,
> would
> > it?
> >
> > Also, I'm for making this API change (as you mentioned, it's an
> improvement)
> > as long as it would make it in before 1.0 final.
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: Rod Johnson [mailto:rod...@in...]
> > Sent: Friday, November 07, 2003 7:45 AM
> > To: spr...@li...
> > Cc: Bob Lee
> > Subject: [Springframework-developer] AOP API
> >
> >
> > All,
> >
> > I've recently been discussing our pointcut API with Bob Lee (of
> > jAdvise,
> AOP
> > Alliance and "Bitter EJB").
> >
> > Bob is currently using Spring AOP and wants the ability to reuse
> > pointcuts independently of interceptors.
> >
> > This seems a reasonable thing to do, so I've been wondering whether
> > it's correct to model a Pointcut as having an interceptor, 
> as Spring 
> > AOP presently does. Perhaps pointcuts should be independent of 
> > interceptors,
> and
> > there should be a new Aspect type that contains a Pointcut _and_ an
> > Interceptor. The methods on ProxyConfig could add and 
> remove this new 
> > type (with the Interceptor methods kept for convenience), 
> and it would 
> > need to
> be
> > hooked up instead of MethodPointcut in bean factories.
> >
> > Bob suggested that the ProxyConfig methods could take both 
> a Pointcut
> _and_
> > an Interceptor, but we really need a single umbrella object 
> for use in
> bean
> > factories.
> >
> > Something like
> >
> > interface Aspect {
> >     [Method]Pointcut getPointcut();
> >     Interceptor getInterceptor();
> > }
> >
> >
> > Perhaps it could be generalized to hold a List of 
> Interceptor, rather
> > than
> a
> > single interceptor. As this would complicate the implementation, I'd
> > like feedback on whether it's really necessary.
> >
> > Calling such a new object "Advice" would  be more 
> AspectJ-like, but I
> think
> > Aspect is clearer.
> >
> > I'm a bit reluctant to change the public API at this stage, but I
> > think
> this
> > would be an improvement. A convenient implementation of Aspect could
> extend
> > RegexpMethodPointcut, making usage similar to the existing pattern.
> >
> > Any thoughts? AOP users, would you mind the impact this 
> would have on
> > your code? (It wouldn't be too difficult to migrate.)
> >
> > Regards,
> > Rod
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program. Does
> > SourceForge.net help you be more productive?  Does it
> > help you create better code?   SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/ 
> > _______________________________________________
> > Springframework-developer mailing list 
> > Spr...@li...
> > 
> https://lists.sourceforge.net/lists/listinfo/s> pringframework-developer
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program. Does
> > SourceForge.net help you be more productive?  Does it
> > help you create better code?   SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/ 
> > _______________________________________________
> > Springframework-developer mailing list 
> > Spr...@li...
> > 
> https://lists.sourceforge.net/lists/listinfo/s> pringframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. Does
> SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 