Re: [Springframework-developer] AOP API

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

Bob,

You've convinced me. I think a ClassPointcut makes sense, and a special kind
of IntroductionAdvice is a good idea.

So I think the Advice interface I proposed earlier could become

    getInterceptor();
    getMethodPointcut();
    getClassPointcut();

Either getMethodPointcut() or getClassPointcut() could return null. If both
returned null, the pointcut would always apply. Class pointcut returning
null means it applies to all classes; method pointcut returning null means
it applies to all methods.

Should this stay called "Advice" or "InterceptionAdvice" as Bob suggests?
IntroductionAdvice _is_ interception advice, so maybe just advice is better
for interception advice?

And the new IntroductionAdvice could look as Bob suggested:

    getInterceptor();
    getInterfaces();
    getClassPointcut();

Although we don't do class loading stuff, Spring isn't limited to advice on
specific proxies because of the new "auto proxying" features, in which a
BeanPostProcessor can create proxies automagically around any bean.

Regards,
Rod

----- Original Message ----- 
From: "Bob Lee" <cra...@cr...>
To: <spr...@li...>;
<rod...@in...>
Sent: Friday, November 07, 2003 8:40 PM
Subject: Re: [Springframework-developer] Fw: Memento Pattern


> I think having separate class and method pointcuts is important for two
> reasons:
>
> 1) Introductions map at class granularity, not method.
>
> 2) Performance. If a pointcut doesn't map to a given class, why recall
> it for every method?
>
> This doesn't make much of a difference in the scope of a simple
> ProxyFactory. Which interceptors map to which classes is in the code
> that uses the factory. If you want to move to a more generic factory,
> class pointcuts will be important.
>
> Thanks,
> Bob
>
> Rod Johnson wrote:
>
> >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_comp
l
>
>ete_sender_verify_callout/451-Could_not_complete_sender_verify_callout_for_
<
>
>cra...@cr...>./451-The_mail_server(s)_for_the_domain_may_be_tempor
a
>
>rily_unreachable,_or/451-they_may_be_permanently_unreachable_from_this_serv
e
>
>r._In_the_latter_case,/451-you_need_to_change_the_address_or_create_an_MX_r
e
>
>cord_for_its_domain/451-if_it_is_supposed_to_be_generally_accessible_from_t
h
>
>e_Internet./451_Talk_to_your_mail_administrator_for_details./Giving_up_on_6
6
> >.35.250.206./
> >
> >
> >>I wonder what changed...
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >-------------------------------------------------------
> >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
> >
> >
>
>
>