[Springframework-developer] Re: AOP API

[roger h. <apo...@sn...>]

I'm not sure about the packaging and naming of Advice and Aspect
functionality, but on the narrower question of Bob's desire to reuse
pointcuts, could you not to just reverse the existing linkage between
pointcuts & interceptors ? ie.

public interface PointcutMethodInterceptor extends MethodInterceptor {

    MethodPointcut getMethodPointcut();

}

public interface MethodPointcut {
}

with other pointcut interfaces unchanged - ie StaticMethodPointcut and
DynamicMethodPointcut continue to extend MethodPointcut.

Any MethodInterceptor that does not implement PointcutMethodInterceptor
would implicitly be 'always invoked'.

Would this not fix Bob's problem ?

It would certainly liberate Pointcuts from Interceptors...

Roger


"Rod Johnson" <rod...@in...> wrote in message
news:1d3a01c3a52c$e4a29470$3800a8c0@chopin...
> 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/