Menu
▾
▴
RE: [Springframework-developer] AOP API
|
From: renaud <re...@ao...> - 2003-11-08 12:40:51
|
> So I think the Advice interface I proposed earlier could become
>
> getInterceptor();
> getMethodPointcut();
> getClassPointcut();
I am not sure about this distinction. It makes the interface less
staightforward. Why wouldn't it be handled by the pointcut. It is more
abstract. Besides I do not think that the method and class part of the
poinctut should be called pointcut, because, in fact, they are not. Why not
having a pointcut formed our of a set of what we would call "designator".
Something like:
interface Advice {
Pointcut getPointcut();
Interceptor getInterceptor();
} // remains the same...
interface Pointcut {
MethodDesignator getMethodDesignator();
ClassDesignator getClassDesignator();
}
Moreover, I do not think that introduction needs a pointcut to work fine. So
I would say something like:
interface Introduction {
ClassDesignator getClassDesignator();
Class[] getInterfaces();
... // then I am not sure about what is needed here. I don't understand
// Bob's proposal including an interceptor.
}
Renaud.
>
> 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_verif
> y_callout_
> >for_
> <
> >
> >cra...@cr...>./451-The_mail_server(s)_for_the_domain
> _may_be_te
> >mpor
> 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_acc
> essible_fr
> >om_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-develope
> > >r
> > >
> > >
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> 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
>
|
