RE: [Springframework-developer] AOP API

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Just some additional thoughts. May help in the future.

We do not have to follow AspectJ, of course not. But AspectJ is clean and
its semantics is well defined. So, here is a simple AspectJ example. 

aspect SimpleTracing {
   pointcut tracedCall(): call(void SomeClass.aMethod(Parameter))
                          ||call(void OtherClass.*(..));

   before(): tracedCall() {
       System.out.println("Entering: " + thisJoinPoint);
   }
}

If we refer to this simple example, an aspect obviously contains pointcuts
(first construct, you can have as many as you want). It also contains some
other constructs called advice (before, after, around -- here there is only
a before advice). If we look at the example, advice contains a reference to
a pointcut and an advice code definition. If the advice code can be
considered equivalent to an interceptor (this is not completely true but it
is fair enough). Then we have the following model:

interface Aspect {
    Pointcut[] getPointcuts();
    Advice[] getAdvice();
}

interface Advice {
    Poincut getPointcut();
    Interceptor getInterceptor();
}

This is very close from the Rod's model, except that the aspect have the
ability to hold pointcut without a correponding interceptor. In fact the
aspect can act like a pointcut repository (getPointcuts() method), which
certainly makes sense but is not useful here if your pointcuts can already
be accessed by any other means.

Hope it clarifies things and not the contrary.

Renaud.

> 
> Dmitriy.
> 
> -----Original Message-----
> From: Kopylenko, Dmitry [mailto:dko...@ac...] 
> Sent: Friday, November 07, 2003 2:38 PM
> To: 'spr...@li...'
> Subject: RE: [Springframework-developer] AOP API
> 
> 
> Currently (in Spring) you could have a MethodPointcut (with 
> an interceptor) or MethodInterceptor without pointcut (well 
> with AlwaysInvoked pointcut). So, the same thing would be 
> here, in an Aspect you would heve either Pointcuts or 
> Interceptors or both. The typical MethodPointcut would look like this:
> 
>  public MyMethodPointcut implements StaticMethodPointcut 
> extends TransactionInterceptor{} or
> 
>  public MyMethodPointcut implements StaticMethodPointcut, 
> MethodInterceptor{}
> 
> If I am way off in my thinking, I'll stick with Rod's proposal.
> 
> Regards,
> Dmitriy.
>  
>  
>                  
> 
> -----Original Message-----
> From: renaud [mailto:re...@ao...] 
> Sent: Friday, November 07, 2003 2:21 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] AOP API
> 
> 
> 
> > Well, following AspectJ terminology the Advice is the construct that
> > implements the crosscutting behavior (Interceptor in our case) and 
> > Aspect is the collection of Advice and Pointcuts. But Pointcut _is 
> > not_ Advice. So, how about:
> > 
> >  public interfce Advice{}
> >  
> >  public interface Interceptor extends Advice{}
> > 
> >  public interface Aspect {
> >     Advice[] getAdvice();
> >     Pointcut[] getPointcut();
> > }
> 
> That's close to my first draft, but how do you link advice 
> and pointcuts then??
> 
> As I said in my previous email, Rod's proposal gets my vote 
> for the moment.
> 
> Regards,
> Renaud.
> 
> > 
> > Regards,
> > Dmitriy.
> > 
> > -----Original Message-----
> > From: renaud [mailto:re...@ao...]
> > Sent: Friday, November 07, 2003 2:02 PM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] AOP API
> > 
> > 
> > > 
> > > > > public interface Advice {
> > > > >     getInterceptor();
> > > > >     getPointcut();
> > > > > }
> > > >
> > > > I agree with the construct here and I like it. However, the
> > > > terminology is quite confusing. It does not stick with 
> usual AOP 
> > > > terminology (e.g. AspectJ).
> > > >
> > > > What about (random thought):
> > > >
> > > > public interface AdvisedPointcut {
> > > >     getInterceptor();
> > > >     getPointcut();
> > > > }
> > > 
> > > I'm open to suggestions as to naming.  AdvisedPointcut 
> makes sense,
> > > but didn't initially appeal to me.
> > > 
> > > AspectElement? To make it clear that it could be a unit of
> > composition
> > > in more complex aspects (as in the additional Aspect interface I
> > > proposed).
> > 
> > Ummm...
> > Having a second thought, I was wrong. Advice makes sense within the
> > AOP terminology. If you look at AspectJ, your advice contains a 
> > pointcut *and* a code (the interceptor
> > part) -- the idea is that you can have abstract pointcuts
> > that you can then refine in subclasses of the aspects.
> > 
> > So, finally, I like very much:
> > 
> > public interface Advice {
> >     getInterceptor();
> >     getPointcut();
> > }
> > 
> > And of course the subsequent:
> > 
> > public interface Aspect {
> >     Advice[] getAdvice();
> > }
> > 
> > +1 for me.
> > 
> > Renaud.
> > 
> > 
> > > 
> > > Regards,
> > > Rod
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by: ApacheCon 2003,
> > > 16-19 November in Las Vegas. Learn firsthand the latest
> > developments
> > > in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!
> > > http://www.apachecon.com/ 
> > > _______________________________________________
> > > Springframework-developer mailing list 
> > > Spr...@li...
> > > 
> > https://lists.sourceforge.net/lists/listinfo/s>
> > pringframework-developer
> > > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by: ApacheCon 2003,
> > 16-19 November in Las Vegas. Learn firsthand the latest developments
> > in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! 
> > http://www.apachecon.com/ 
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > 
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by: ApacheCon 2003,
> > 16-19 November in Las Vegas. Learn firsthand the latest developments
> > in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! 
> > http://www.apachecon.com/ 
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > 
> https://lists.sourceforge.net/lists/listinfo/s> pringframework-developer
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest 
> developments in
> Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!
> http://www.apachecon.com/ 
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest 
> developments in
> Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!
> http://www.apachecon.com/ 
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 