Re: [Springframework-developer] AOP API

[Rod J. <rod...@in...>]

I'm now thinking along the lines of:

public interface Advice {
    getInterceptor();
    getPointcut();
}

Implementing this will be a good start, and would address the Pointcut reuse
issue.

A possible next step might be to have:

public interface Aspect {
    Advice[] getAdvice();
}

This would enable composition into integrated aspects. However, I'm not sure
we need this right now. After all, Spring has a powerful means of
integration already via the BeanFactory. And we could always drop the
higher-level Aspect in in a later version: it shouldn't break existing code.

Roger, I can see your point, but I think that, whichever way around it is,
the inheritance is the problem, and replacing it with composition makes more
sense.

Regards,
Rod

----- Original Message ----- 
From: "Kopylenko, Dmitry" <dko...@su...>
To: <spr...@li...>
Sent: Friday, November 07, 2003 2:27 PM
Subject: RE: [Springframework-developer] AOP API


> +1 for pointcut-interceptor pairs
>
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, November 07, 2003 9:24 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] AOP API
>
>
> +1, I think this is our last chance to change public APIs. I really
> +don't
> want to do this after M3.
>
> So we need to make sure we get it right.
>
> We could simply provide an "Aspect" that has one pointcut and one
> interceptor. Or we could have one pointcut and multiple interceptors
(harder
> to justify). Or a set of pointcut-interceptor pairs, as Renaud suggested.
Or
> is there another mechanism of composition we could provide?
>
> Regards,
> Rod
>
> ----- Original Message ----- 
> From: "Colin Sampaleanu" <col...@ex...>
> To: <spr...@li...>
> Cc: "Bob Lee" <cra...@cr...>
> Sent: Friday, November 07, 2003 1:50 PM
> Subject: Re: [Springframework-developer] AOP API
>
>
> > 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
> > >
> > >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
>