springframework-developer — Spring Framework developers list

Re: [Springframework-developer] AOP API

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

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

That was my original reason (that AspectJ advice is both pointcut and code).

"Advice" is nice and simple.

Regards,
Rod

RE: [Springframework-developer] AOP API

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

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
> 

[Springframework-developer] Fw: Memento Pattern

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

Forwarded on behalf of Bob, who's having problems posting to the list...

I think this is actually not dissimilar to what I proposed, with the
IntroductionAdvice corresponding to my Advice.

I think the present MethodPointcut can cover both Class and method case.

I think we should introduce a new "Pointcut" superinterface for
MethodPointcut, even if it's a tag interface at present, and have Advice
return Pointcut, not MethodPointcut. Although I don't think Spring should
support field interception, and don't much like it in principle, we
shouldn't rule options out in our API.

I'm  inclining towards implementing the Advice interface I proposed. I'm not
planning to implement the Aspect interface for now, supporting multiple
Advices in one object, although that can be added later.

Regards,
Rod

----- Original Message ----- 
From: "Bob Lee" <cra...@cr...>
To: "Rod Johnson" <rod...@in...>
Sent: Friday, November 07, 2003 7:41 PM
Subject: Re: Memento Pattern


> Rod,
>
> I keep getting an error when I try to send to the list (detailed below).
>
> Here's my suggestion for the interfaces:
>
> interface ClassCut {
>   boolean appliesTo(Class clazz, ...);
> }
>
> interface MethodCut {
>   boolean appliesTo(Method method, ...);
> }
>
> interface InterceptionAdvice {
>   ClassCut getClassCut();
>   MethodCut getMethodCut();
>   [Method]Interceptor getInterceptor();
> }
>
> interface IntroductionAdvice {
>   ClassCut getClassCut();
>   Class[] getInterfaces();
>   [Method]Interceptor getInterceptor();
> }
>
> This gives you the separation and orthogonality you need and leaves the
> door open for performance optimization.
>
> You could refactor out an Advice super interface, but I don't see the
> benefit.
>
> Thanks,
> Bob
>
> P.S. I was able to send okay the other day. Here's the mail error:
>
> Nov  7 14:26:52 server qmail: 1068236812.632418 starting delivery 34:
> msg 4337993 to remote spr...@li...
> Nov  7 14:26:52 server qmail: 1068236812.632437 status: local 0/10
> remote 1/20
> Nov  7 14:27:08 server qmail: 1068236828.373999 delivery 34: deferral:
>
66.35.250.206_does_not_like_recipient./Remote_host_said:_451-Could_not_compl
ete_sender_verify_callout/451-Could_not_complete_sender_verify_callout_for_<
cra...@cr...>./451-The_mail_server(s)_for_the_domain_may_be_tempora
rily_unreachable,_or/451-they_may_be_permanently_unreachable_from_this_serve
r._In_the_latter_case,/451-you_need_to_change_the_address_or_create_an_MX_re
cord_for_its_domain/451-if_it_is_supposed_to_be_generally_accessible_from_th
e_Internet./451_Talk_to_your_mail_administrator_for_details./Giving_up_on_66
.35.250.206./
>
> I wonder what changed...
>
>
>
>

RE: [Springframework-developer] AOP API

[Kopylenko, D. <dko...@ac...>]

Well again, I am contradicting myself. If we follow AspecJ terminology,
Pointcuts should not have actual implementation of the concern only rules to
apply Advice to Joinpoints. But we don't have to strictly follow AspectJ.

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

RE: [Springframework-developer] AOP API

[Kopylenko, D. <dko...@ac...>]

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

RE: [Springframework-developer] AOP API

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

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

RE: [Springframework-developer] AOP API

[Kopylenko, D. <dko...@ac...>]

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();
}

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

RE: [Springframework-developer] AOP API

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

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

Re: [Springframework-developer] AOP API

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

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

Regards,
Rod

RE: [Springframework-developer] AOP API

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

> 
> I'm now thinking along the lines of:
> 
> 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();
}

- Renaud.

> 
> 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-develop
> > > er
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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/s> pringframework-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/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
> 

[Springframework-developer] Re: AOP API

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

Would certainly agree that composition is more appealing ;)

Roger


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

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
>

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
> 

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

RE: [Springframework-developer] AOP API

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

I think that nobody has already implemented the org.aopalliance.aop.Aspect
interface because its goals are not very clearly defined. Having a
standardization effort is a good but difficult thing because we should agree
on what we want to standardize, but also on the goals of the
standardization. Indeed, implementing common interfaces will not
automaically make two frameworks compatible. For example, JAC and Spring
both implement the org.aopalliance.intercept interface. This does not make
Spring and JAC more compatible because their implementations diverge very
fast.

I am currently investigating the possibility to reshape the AOP Alliance
goals, strategy, and environment so that it becomes better defined and, if
possible, funded with academics projects. So I do not think that Spring
should absolutly try to implement all the AOP Alliance interfaces for the
moment, but just tend towards the better and more generic solution.

So, +1 for pointcut-interceptor paris... oops, pairs :-)

PS: I am currently just starting to take a closer look at the Spring API.
I'll know more in a few days and I will be able to better participate.

---
Renaud Pawlak
Software Engineering Department
Rensselaer at Hartford
275 Windsor St, Hartford, CT 06120-2991
Work: 860-548-5358 Mobile: 860-748-5527
Emails: pa...@rh..., re...@ao...
WWW: http://www.lifl.fr/~pawlak


> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of Kopylenko, Dmitry
> Sent: Friday, November 07, 2003 9:01 AM
> To: 'spr...@li...'
> Subject: RE: [Springframework-developer] AOP API
> 
> 
> So,
> 
> Could we rework org.aopalliance.aop.Aspect interface or we 
> should stick with Spring one? Has anyone implemented 
> org.aopalliance.aop package yet?
> 
> Dmitriy.
> 
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...] 
> Sent: Friday, November 07, 2003 8:52 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] AOP API
> 
> 
> Comments from Renaud Pawlak (JAC, AOP Alliance) on the 
> proposed change:
> 
> > Btw, I'm considering changing the Spring AOP API so that 
> there's a new
> > type, Aspect, that will contain both a Pointcut and an Interceptor. 
> > This way pointcuts can be reused. What's your view on that?
> 
> <renaud>
> I agree because an aspect component in JAC would correspond 
> to this. However, an aspect should be able to contain a set 
> of pointcut-interceptor pairs rather than ony one. Indeed, in 
> the general case, a crosscutting concern is not about 
> modularizing only one piece of advice but several ones 
> related to the same concern (e.g. authentication). Having 
> only one interceptor per aspect would be a little bit like 
> authorizing only one method per object in OOP... </renaud>
> 
> I think this is a good point. A convenience implementation of 
> Aspect could take care of the common "single interceptor and 
> pointcut" case avoiding complicating typical usage.
> 
> Regards,
> Rod
> 
> ----- Original Message ----- 
> From: "Kopylenko, Dmitry" <dko...@su...>
> To: <spr...@li...>
> Sent: Friday, November 07, 2003 1:27 PM
> Subject: RE: [Springframework-developer] AOP API
> 
> 
> > Rod,
> >
> > Funny you should mention that, but I was thinking along the 
> same lines
> > a
> few
> > days ago :-) Aspect would represent the right level of 
> abstraction as
> > Interceptors and Pointcuts are just "implementation 
> instruments" of it 
> > (certain Aspect). I was thinking to utilize (somehow) existing 
> > org.aopalliance.aop.Aspect but the current API wouldn't fit 
> the model,
> would
> > it?
> >
> > Also, I'm for making this API change (as you mentioned, it's an
> improvement)
> > as long as it would make it in before 1.0 final.
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: Rod Johnson [mailto:rod...@in...]
> > Sent: Friday, November 07, 2003 7:45 AM
> > To: spr...@li...
> > Cc: Bob Lee
> > Subject: [Springframework-developer] AOP API
> >
> >
> > 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/s> pringframework-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/s> pringframework-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
> 

RE: [Springframework-developer] AOP API

[Kopylenko, D. <dko...@ac...>]

+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

RE: [Springframework-developer] AOP API

[Kopylenko, D. <dko...@ac...>]

http://aopalliance.sourceforge.net/doc/org/aopalliance/aop/Aspect.html

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...] 
Sent: Friday, November 07, 2003 9:23 AM
To: spr...@li...
Subject: Re: [Springframework-developer] AOP API


Am I missing something? I can't find this AOP Alliance interface.

Regards,
Rod

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


> So,
>
> Could we rework org.aopalliance.aop.Aspect interface or we should 
> stick
with
> Spring one? Has anyone implemented org.aopalliance.aop package yet?
>
> Dmitriy.
>
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, November 07, 2003 8:52 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] AOP API
>
>
> Comments from Renaud Pawlak (JAC, AOP Alliance) on the proposed 
> change:
>
> > Btw, I'm considering changing the Spring AOP API so that there's a 
> > new type, Aspect, that will contain both a Pointcut and an 
> > Interceptor. This way pointcuts can be reused. What's your view on 
> > that?
>
> <renaud>
> I agree because an aspect component in JAC would correspond to this. 
> However, an aspect should be able to contain a set of 
> pointcut-interceptor pairs rather than ony one. Indeed, in the general 
> case, a crosscutting concern is not about modularizing only one piece 
> of advice but several
ones
> related to the same concern (e.g. authentication). Having only one 
> interceptor per aspect would be a little bit like authorizing only one 
> method per object in OOP... </renaud>
>
> I think this is a good point. A convenience implementation of Aspect 
> could take care of the common "single interceptor and pointcut" case 
> avoiding complicating typical usage.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "Kopylenko, Dmitry" <dko...@su...>
> To: <spr...@li...>
> Sent: Friday, November 07, 2003 1:27 PM
> Subject: RE: [Springframework-developer] AOP API
>
>
> > Rod,
> >
> > Funny you should mention that, but I was thinking along the same 
> > lines a
> few
> > days ago :-) Aspect would represent the right level of abstraction 
> > as Interceptors and Pointcuts are just "implementation instruments" 
> > of it (certain Aspect). I was thinking to utilize (somehow) existing 
> > org.aopalliance.aop.Aspect but the current API wouldn't fit the 
> > model,
> would
> > it?
> >
> > Also, I'm for making this API change (as you mentioned, it's an
> improvement)
> > as long as it would make it in before 1.0 final.
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: Rod Johnson [mailto:rod...@in...]
> > Sent: Friday, November 07, 2003 7:45 AM
> > To: spr...@li...
> > Cc: Bob Lee
> > Subject: [Springframework-developer] AOP API
> >
> >
> > 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-develop
> > er
> >
> >
> > -------------------------------------------------------
> > 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-develop
> > er
>
>
>
>
> -------------------------------------------------------
> 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

Re: [Springframework-developer] AOP API

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

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

Re: [Springframework-developer] AOP API

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

Am I missing something? I can't find this AOP Alliance interface.

Regards,
Rod

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


> So,
>
> Could we rework org.aopalliance.aop.Aspect interface or we should stick
with
> Spring one? Has anyone implemented org.aopalliance.aop package yet?
>
> Dmitriy.
>
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, November 07, 2003 8:52 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] AOP API
>
>
> Comments from Renaud Pawlak (JAC, AOP Alliance) on the proposed change:
>
> > Btw, I'm considering changing the Spring AOP API so that there's a new
> > type, Aspect, that will contain both a Pointcut and an Interceptor.
> > This way pointcuts can be reused. What's your view on that?
>
> <renaud>
> I agree because an aspect component in JAC would correspond to this.
> However, an aspect should be able to contain a set of pointcut-interceptor
> pairs rather than ony one. Indeed, in the general case, a crosscutting
> concern is not about modularizing only one piece of advice but several
ones
> related to the same concern (e.g. authentication). Having only one
> interceptor per aspect would be a little bit like authorizing only one
> method per object in OOP... </renaud>
>
> I think this is a good point. A convenience implementation of Aspect could
> take care of the common "single interceptor and pointcut" case avoiding
> complicating typical usage.
>
> Regards,
> Rod
>
> ----- Original Message ----- 
> From: "Kopylenko, Dmitry" <dko...@su...>
> To: <spr...@li...>
> Sent: Friday, November 07, 2003 1:27 PM
> Subject: RE: [Springframework-developer] AOP API
>
>
> > Rod,
> >
> > Funny you should mention that, but I was thinking along the same lines
> > a
> few
> > days ago :-) Aspect would represent the right level of abstraction as
> > Interceptors and Pointcuts are just "implementation instruments" of it
> > (certain Aspect). I was thinking to utilize (somehow) existing
> > org.aopalliance.aop.Aspect but the current API wouldn't fit the model,
> would
> > it?
> >
> > Also, I'm for making this API change (as you mentioned, it's an
> improvement)
> > as long as it would make it in before 1.0 final.
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: Rod Johnson [mailto:rod...@in...]
> > Sent: Friday, November 07, 2003 7:45 AM
> > To: spr...@li...
> > Cc: Bob Lee
> > Subject: [Springframework-developer] AOP API
> >
> >
> > 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
>
>
> -------------------------------------------------------
> 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
>

RE: [Springframework-developer] AOP API

[Kopylenko, D. <dko...@ac...>]

So,

Could we rework org.aopalliance.aop.Aspect interface or we should stick with
Spring one? Has anyone implemented org.aopalliance.aop package yet?

Dmitriy.

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...] 
Sent: Friday, November 07, 2003 8:52 AM
To: spr...@li...
Subject: Re: [Springframework-developer] AOP API


Comments from Renaud Pawlak (JAC, AOP Alliance) on the proposed change:

> Btw, I'm considering changing the Spring AOP API so that there's a new 
> type, Aspect, that will contain both a Pointcut and an Interceptor. 
> This way pointcuts can be reused. What's your view on that?

<renaud>
I agree because an aspect component in JAC would correspond to this.
However, an aspect should be able to contain a set of pointcut-interceptor
pairs rather than ony one. Indeed, in the general case, a crosscutting
concern is not about modularizing only one piece of advice but several ones
related to the same concern (e.g. authentication). Having only one
interceptor per aspect would be a little bit like authorizing only one
method per object in OOP... </renaud>

I think this is a good point. A convenience implementation of Aspect could
take care of the common "single interceptor and pointcut" case avoiding
complicating typical usage.

Regards,
Rod

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


> Rod,
>
> Funny you should mention that, but I was thinking along the same lines 
> a
few
> days ago :-) Aspect would represent the right level of abstraction as 
> Interceptors and Pointcuts are just "implementation instruments" of it 
> (certain Aspect). I was thinking to utilize (somehow) existing 
> org.aopalliance.aop.Aspect but the current API wouldn't fit the model,
would
> it?
>
> Also, I'm for making this API change (as you mentioned, it's an
improvement)
> as long as it would make it in before 1.0 final.
>
> Regards,
> Dmitriy.
>
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, November 07, 2003 7:45 AM
> To: spr...@li...
> Cc: Bob Lee
> Subject: [Springframework-developer] AOP API
>
>
> 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

Re: [Springframework-developer] AOP API

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

Comments from Renaud Pawlak (JAC, AOP Alliance) on the proposed change:

> Btw, I'm considering changing the Spring AOP API so that
> there's a new type, Aspect, that will contain both a Pointcut
> and an Interceptor. This way pointcuts can be reused. What's
> your view on that?

<renaud>
I agree because an aspect component in JAC would correspond to this.
However, an aspect should be able to contain a set of pointcut-interceptor
pairs rather than ony one. Indeed, in the general case, a crosscutting
concern is not about modularizing only one piece of advice but several ones
related to the same concern (e.g. authentication). Having only one
interceptor per aspect would be a little bit like authorizing only one
method per object in OOP...
</renaud>

I think this is a good point. A convenience implementation of Aspect could
take care of the common "single interceptor and pointcut" case avoiding
complicating typical usage.

Regards,
Rod

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


> Rod,
>
> Funny you should mention that, but I was thinking along the same lines a
few
> days ago :-) Aspect would represent the right level of abstraction as
> Interceptors and Pointcuts are just "implementation instruments" of it
> (certain Aspect). I was thinking to utilize (somehow) existing
> org.aopalliance.aop.Aspect but the current API wouldn't fit the model,
would
> it?
>
> Also, I'm for making this API change (as you mentioned, it's an
improvement)
> as long as it would make it in before 1.0 final.
>
> Regards,
> Dmitriy.
>
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, November 07, 2003 7:45 AM
> To: spr...@li...
> Cc: Bob Lee
> Subject: [Springframework-developer] AOP API
>
>
> 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

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

RE: [Springframework-developer] AOP API

[Kopylenko, D. <dko...@ac...>]

Rod,

Funny you should mention that, but I was thinking along the same lines a few
days ago :-) Aspect would represent the right level of abstraction as
Interceptors and Pointcuts are just "implementation instruments" of it
(certain Aspect). I was thinking to utilize (somehow) existing
org.aopalliance.aop.Aspect but the current API wouldn't fit the model, would
it?

Also, I'm for making this API change (as you mentioned, it's an improvement)
as long as it would make it in before 1.0 final.

Regards,
Dmitriy.

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...] 
Sent: Friday, November 07, 2003 7:45 AM
To: spr...@li...
Cc: Bob Lee
Subject: [Springframework-developer] AOP API


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

[Springframework-developer] AOP API

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

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

[Springframework-developer] Documentation

[Alef A. \(JTeam\) <al...@jt...>]

New version of the PDF is in the CVS (root of the docs directory). It
seems that DocBook is going to be it, having good results here and am
also able to customize stuff if I want, so I'm pretty happy. About the
image stuff (thomas?) in HTML, I've been able to produce quite
reasonable html so that's no problem as well... No images yet in the
spring pdf though...

I've basically finished the beans package (apart form some - for me -
minor things like event handling and vetoing) but am not quite satisfied
yet about the form. I'll probably have to elaborate some more on some
pieces. We'll have to see how it works when writing more documentation
(because the baens package still is the basis for a lot of stuff and
probably has to be referred to a lot)...

I'll see what I can do tomorrow and over the weekend. I might check in
the sources for the docs after the weekend (unless there's major
objections). I'm planning one working on the context stuff next. Mail
and valiation shouldn't be too much work. Anybody has other input that
might prevent me from doing duplicate stuff?

Alef