Re: [Springframework-developer] AOP API

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

I'm ok with this. It makes sense, and it will be a lot harder to justify 
breaking the API later. My own code that is affected will be pretty easy 
to refactor.


Rod Johnson wrote:

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