RE: [Springframework-developer] AOP API

[Kopylenko, D. <dko...@ac...>]

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




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