RE: [Springframework-developer] Re: AOP API

[renaud <re...@ao...>]

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

In fact I do not think that there should be any logical dependency between
pointcuts and advice (in any direction). Both of them should be reused in
the context of an aspect. That is why I would propose something like:

interface Aspect {
   Pointcut[] getPointcuts();
   Advice[] getAdvices(); // advices can be interceptors
   Pointcut getLinkedPointcut(Advice); // these too methods create the
logical links
   Advice getLinkedAdvice(Pointcut);   // between the advices and the
pointcut within this aspect
}

interface Advice {
   Aspect getAspect();
}

interface Pointcut {
   Aspect getAspect();
}

Note that getAspect() can be factorized in parent interface "AspectElement".

- Renaud.

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