springframework-developer — Spring Framework developers list

Fw: [Springframework-developer] AOP API proposal

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

Renaud's comments:

> Seems ok for me.
> I still do not think that AttributeRegistery sould be passed as a
parameter.

Perhaps we should just leave Attribute access up to pointcut
implementations.

> I am not sure about the composition of the pointcuts. "and" is a kind of
> union of two pointcuts. Why not having an intersection possibility?
> In that case. "union" and "inter" would maybe be better names?

[RJ] Other operations also could be added. But I agree that "and" is
potentially confusing.

Perhaps we could have :

-  "intersection" when both pointcuts must be satisfied (I don't like
abbreviations without good reason)
- "union" when either pointcut must be satisfied

I think moving composition out of the class hierarchy and into static
methods will allow us to add arbitrary combinations without modifying the
core interfaces.

Regards,
Rod

[Springframework-developer] Re: AOP API proposal

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

Hi Rod

I like the look of the new API and the thrust of the changes.

The following comments are in line the ones I made yesterday.

When defining an IntroductionAdvice and an IntroductionInterceptor, how
about the use of a single Declared Interface, rather than a list of
Implemented Interfaces, ie:

public interface IntroductionAdvice extends Advice {

    IntroductionInterceptor getIntroductionInterceptor();

    Class getInterface();      // single declared interface

}

public IntroductionInterceptor extends Interceptor {

    Class getDeclaredInterface();         // single declared interface

    Class[] getIntroducedInterfaces()   // as at present

}

The advantage this offers is that within a given factory it then becomes
possible to bind the IntroductionInterceptors against the Declared
Interface name for which they contract to supply an implementation.

With the interfaces you are proposing, how would you select between a pair
of IntroductionInterceptors that both 'implement' a set of common interfaces
?

By way of example:

interface Ia { ... }
interface Ib extends Ia { ... }
interface Ic extends Ib { ... }

class InterceptorOne implements Ia, Ib, IntroductionInterceptor {
    Class getDeclaredInterface() {
        return Ib;
    }
    ....
}

class InterceptorTwo implements Ia, Ib, Ic, IntroductionInterceptor {
    Class getDeclaredInterface() {
        return Ic;
    }
    ....
}

If I want to find an IntroductionInterceptor that will provide an
implementation supporting Ia and Ib, with things as you propose, I would
need to know details about the 'actual introduction interceptor classes
available in the bean factory', before I could select one.  Conversely, if
each introduction interceptor declares a single defining interface for
which it contracts to provide an implementation, I only need to specify that
I would like an introduction that implements Ib, or conversely one that
implements Ic - without having to know anything about the actual
introduction classes that may be able to deliver this....

In short, I would like to be able to select an IntroductionInterceptor by
specifying a single Declared type - just as a Class declares / defines a
single type for the collection of super types that it implements.

Apologies if this sounds like I am labouring a point - I probably am - but I
would be interested to know what you think ?

Apart from this one issue, the rest looks great - as usual you gave a great
eye for 'as simple as possible -- but no simpler'

Roger



"Rod Johnson" <rod...@in...> wrote in message
news:20f701c3a6c2$de7c4c20$3800a8c0@chopin...
> I attach a proposal for a revised AOP API. (Use wordwrap.)
>
> This incorporates several of Bob's suggestions, but isn't a radical
> overturning of present Spring AOP concepts.
>
> I think it achieves the following major goals:
>
> - enable pointcut and interceptor reuse, independently
> - support pointcut composition
> - allow optimization by creating pointcuts that exclude whole classes
> without the need to check at method level
> - improve the introduction mechanism
> - allow the packaging of multiple advices into an Aspect. (In the future;
> I'm not planning to implement that now.)
>
> I've already implemented it: this is not to mean that it's set in stone,
but
> that it's feasible.
>
> Comments, please.
>
> I think it's important that M3 has a new, and stable, AOP API. This means
> that we have to finalize this in the next few days.
>
> Regards,
> Rod
>

Re: [Springframework-developer] Welcome anyone

[<tri...@tr...>]

I created the image by just cutting and pasting from a screenshot of your site.
   The har part was trying to figure out the parts to cut.

Thomas


Quoting yan...@ne...:

> okey,I think it looks very well.The linking picture is very beautiful .Who
> did make it?
> Thank you ,Thomas.
> 
> 
> tri...@tr... wrote:
> 
> >I put a link on the home page.  Let me know if it looks OK, or if it does
> not
> >make sense - can't exactly verify what I put out there.
> >
> >Thomas
> >
> >
> >Quoting Rod Johnson <rod...@in...>:
> >
> >> Good to hear this. Unfortunately I can't read it, but maybe we should
> >> consider linking to it from the Spring home page for those who can.
> >> 
> >> Regards,
> >> Rod
> >> 
> >> ----- Original Message ----- 
> >> From: <yan...@ne...>
> >> To: <spr...@li...>
> >> Sent: Saturday, November 08, 2003 2:23 PM
> >> Subject: [Springframework-developer] Welcome anyone
> >> 
> >> 
> >> > I set up a professional Chinese Spring forum in order to communicate
> with
> >> other Spring fans with chinese. I want to provide a site where Chinese
> can
> >> share spring framework experience with their home language and make the
> use
> >> of spring more widely in China.
> >> >
> >> > Now spring framework Chinese Forum is the "only" professional spring
> forum
> >> in China. Welcome anyone who can read chinese!
> >> >
> >> > http://xglw.51.net/5team/springframework
> >> >
> >> >
> >> > __________________________________________________________________
> >> > McAfee VirusScan Online from the Netscape Network.
> >> > Comprehensive protection for your entire computer. Get your free trial
> >> today!
> >> > http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
> >> >
> >> > Get AOL Instant Messenger 5.1 free of charge.  Download Now!
> >> > http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
> >> >
> >> >
> >> > -------------------------------------------------------
> >> > 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
> >
> 
> __________________________________________________________________
> McAfee VirusScan Online from the Netscape Network.
> Comprehensive protection for your entire computer. Get your free trial
> today!
> http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
> 
> Get AOL Instant Messenger 5.1 free of charge.  Download Now!
> http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
> 
> 
> -------------------------------------------------------
> 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 proposal

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

I attach a proposal for a revised AOP API. (Use wordwrap.)

This incorporates several of Bob's suggestions, but isn't a radical
overturning of present Spring AOP concepts.

I think it achieves the following major goals:

- enable pointcut and interceptor reuse, independently
- support pointcut composition
- allow optimization by creating pointcuts that exclude whole classes
without the need to check at method level
- improve the introduction mechanism
- allow the packaging of multiple advices into an Aspect. (In the future;
I'm not planning to implement that now.)

I've already implemented it: this is not to mean that it's set in stone, but
that it's feasible.

Comments, please.

I think it's important that M3 has a new, and stable, AOP API. This means
that we have to finalize this in the next few days.

Regards,
Rod

Re: [Springframework-developer] Welcome anyone

[<yan...@ne...>]

okey,I think it looks very well.The linking picture is very beautiful .Who did make it?
Thank you ,Thomas.


tri...@tr... wrote:

>I put a link on the home page.  Let me know if it looks OK, or if it does not
>make sense - can't exactly verify what I put out there.
>
>Thomas
>
>
>Quoting Rod Johnson <rod...@in...>:
>
>> Good to hear this. Unfortunately I can't read it, but maybe we should
>> consider linking to it from the Spring home page for those who can.
>> 
>> Regards,
>> Rod
>> 
>> ----- Original Message ----- 
>> From: <yan...@ne...>
>> To: <spr...@li...>
>> Sent: Saturday, November 08, 2003 2:23 PM
>> Subject: [Springframework-developer] Welcome anyone
>> 
>> 
>> > I set up a professional Chinese Spring forum in order to communicate with
>> other Spring fans with chinese. I want to provide a site where Chinese can
>> share spring framework experience with their home language and make the use
>> of spring more widely in China.
>> >
>> > Now spring framework Chinese Forum is the "only" professional spring forum
>> in China. Welcome anyone who can read chinese!
>> >
>> > http://xglw.51.net/5team/springframework
>> >
>> >
>> > __________________________________________________________________
>> > McAfee VirusScan Online from the Netscape Network.
>> > Comprehensive protection for your entire computer. Get your free trial
>> today!
>> > http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
>> >
>> > Get AOL Instant Messenger 5.1 free of charge.  Download Now!
>> > http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
>> >
>> >
>> > -------------------------------------------------------
>> > 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
>

__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

RE: [Springframework-developer] AOP API

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

>=20
> >So I think that a fa=E7ade have to exist in the AOP Alliance=20
> interfaces.
>=20
> I'm not against the concept of having a facade in the AOP=20
> Alliance...if you're in favour of it that changes things a bit.

I always was. But I remember that most of the people were not sure,
especially because of the JSR-175.

> The idea was that the Invocation provides a way to guarantee=20
> the availability of the metadata information without tying in=20
> to Singletons or the like.

Umm, I see.

> However, I agree that in general=20
> metadata attributes are likely to be global. I do think that=20
> it should be possible to have other sources (like
> overrides) of metadata besides classes, so I don't think=20
> JSR-175 is a complete solution. Also it's way into the future.
>=20
> If we do have an AOP Alliance facade for attributes, how=20
> would we access it from pointcuts etc?

Well, since singletons are really not practical, maybe that I could go =
for
having some king of MetadataAware interface, like you suggested before.

Sthng like that?:

interface MetadataAware {
    MetadataFacade getMetadataFacade();
}

And:
MethodInvocation, Pointcut, ... extends MetadataAware

Renaud.

>=20
> Regards,
> Rod
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest=20
> developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV,=20
> and more! http://www.apachecon.com/=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

Re: [Springframework-developer] AOP API

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

>So I think that a façade have to exist in the AOP Alliance interfaces.

I'm not against the concept of having a facade in the AOP Alliance...if
you're in favour of it that changes things a bit.

> One problem with moving away with an AttributeRegistry
> concept on MethodInvocation is that we don't want Pointcuts
> to be dependent on Singleton magic (ie black magic) to get
> metadata: this should be easily pluggable at runtime. Perhaps
> a pointcuts interested in metadata could implement a
> MetadataAware interface and expose an Attributes property.

>However, I've never really understood the metadata attached to the
invocation. For me, metadata are set on the Java meta elements (classes,
fields, methods, ...). They do not depend on the invocation then.

The idea was that the Invocation provides a way to guarantee the
availability of the metadata information without tying in to Singletons or
the like. However, I agree that in general metadata attributes are likely to
be global. I do think that it should be possible to have other sources (like
overrides) of metadata besides classes, so I don't think JSR-175 is a
complete solution. Also it's way into the future.

If we do have an AOP Alliance facade for attributes, how would we access it
from pointcuts etc?

Regards,
Rod

RE: [Springframework-developer] AOP API

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

>=20
> I'm inclined to agree with Bob's suggestion that we should=20
> drop the AttributeRegistry from our pointcut signatures. This=20
> probably means it should go from the AOP Alliance package as=20
> well - Renaud, what's your view on this--not from a Spring=20
> perspective but from an AOP Alliance perspective.

I am more than ever conviced that metadata is a key point of AOP. In
particular, metadata will be extremely useful when configuring the =
aspects.

Moreover, from a recent discussion with Gregor Kiczales, AspectJ will
support metadata based pointcuts as soon as JSR-175 is done.

So I think that a fa=E7ade have to exist in the AOP Alliance interfaces.

> One problem with moving away with an AttributeRegistry=20
> concept on MethodInvocation is that we don't want Pointcuts=20
> to be dependent on Singleton magic (ie black magic) to get=20
> metadata: this should be easily pluggable at runtime. Perhaps=20
> a pointcuts interested in metadata could implement a=20
> MetadataAware interface and expose an Attributes property.

However, I've never really understood the metadata attached to the
invocation. For me, metadata are set on the Java meta elements (classes,
fields, methods, ...). They do not depend on the invocation then.

I you want to have metadata defined for an invocation, it is ok for me, =
but
it has nothing to do with the JSR-175.=20

Renaud.

>=20
>=20
> Views on this?
>=20
> Regards,
> Riod
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest=20
> developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV,=20
> and more! http://www.apachecon.com/=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

[Springframework-developer] AOP API

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

As this is our last opportunity to change the public API significantly--I'd
rather we didn't need to at all, but I think there are enhancements we need
to make with AOP--we should think about the status of the AOP Alliance
AttributeRegistry interface.

I was the only person on the AOP Alliance arguing for this interface. I felt
that metadata was sufficiently important to AOP that to ensure portability
of interceptors we should provide a standard facade API to where they got
their metadata from. However, while I think there's still a need for a
standard facade API for attributes, I don't think the AOP Alliance is going
to provide it.

JSR-175 is now a little closer, although still a fair way from being
available to real projects. Commons Attributes is now looking plausible and
Spring itself will soon provide an attributes API that can sit in front of
other attribute implementations.

I'm inclined to agree with Bob's suggestion that we should drop the
AttributeRegistry from our pointcut signatures. This probably means it
should go from the AOP Alliance package as well - Renaud, what's your view
on this--not from a Spring perspective but from an AOP Alliance perspective.

This shouldn't affect Spring users much as most users are using the
TransactionInterceptor which generally uses a TransactionAttributeSource
rather than the AttributeRegistry. The forthcoming metadata-driven
autoproxying can simply use the Spring metadata API, which can be a facade
in front of Commons Attributes/JSR-175 etc.


One problem with moving away with an AttributeRegistry concept on
MethodInvocation is that we don't want Pointcuts to be dependent on
Singleton magic (ie black magic) to get metadata: this should be easily
pluggable at runtime. Perhaps a pointcuts interested in metadata could
implement a MetadataAware interface and expose an Attributes property.


Views on this?

Regards,
Riod

Re: [Springframework-developer] Welcome anyone

[<tri...@tr...>]

I put a link on the home page.  Let me know if it looks OK, or if it does not
make sense - can't exactly verify what I put out there.

Thomas


Quoting Rod Johnson <rod...@in...>:

> Good to hear this. Unfortunately I can't read it, but maybe we should
> consider linking to it from the Spring home page for those who can.
> 
> Regards,
> Rod
> 
> ----- Original Message ----- 
> From: <yan...@ne...>
> To: <spr...@li...>
> Sent: Saturday, November 08, 2003 2:23 PM
> Subject: [Springframework-developer] Welcome anyone
> 
> 
> > I set up a professional Chinese Spring forum in order to communicate with
> other Spring fans with chinese. I want to provide a site where Chinese can
> share spring framework experience with their home language and make the use
> of spring more widely in China.
> >
> > Now spring framework Chinese Forum is the "only" professional spring forum
> in China. Welcome anyone who can read chinese!
> >
> > http://xglw.51.net/5team/springframework
> >
> >
> > __________________________________________________________________
> > McAfee VirusScan Online from the Netscape Network.
> > Comprehensive protection for your entire computer. Get your free trial
> today!
> > http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
> >
> > Get AOL Instant Messenger 5.1 free of charge.  Download Now!
> > http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
> >
> >
> > -------------------------------------------------------
> > 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] AOP API

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

It seems to me that the concept of an Advice containing Pointcut and
Interceptor is sound and provides a necessary separation.

I also like the idea of a new "IntroductionAdvice".

The challenge is modelling the pointcut itself. Essentially this is a
challenge of modelling something that's basically an expression through an
object model. For example, the TopLink query object model vs HQL or JDOQL.

I think that pointcuts should be objects. So we need to think about how to
combine pointcuts via an object model.

My present thought is to have:

applies(Class) on all pointcuts

applies(Class, Method) additionally on MethodPointcuts

applies(Class, Method, args) additionally on DynamicMethodPointcuts


An inheritance hierarchy does seem a bit odd here; however, I do think that
a pointcut should be complete in itself, and I don't much like the idea of
separate "partial" class and method pointcuts.

Renaud's suggestion of Class and Method "designators" is more elegant
(especially as it would limit IntroductionAdvice to class designators) but
I'm concerned that involves one too many levels of object and isn't the
simplest thing that could possibly work.

A static facade would allow composition of pointcuts, as in:

class Pointcuts {
    static Pointcut and(Pointcut a, Pointcut b);
    ...
}

This could be used to achieve the composition of class and method pointcuts
Bob suggested. E.g.:

Pointcut foo = new ClassPointcutSupport(Foo.class);
Pointcut setters = new MethodPointcutSupport("set*");
Pointcut somethingElse ...
Pointcut fooAndSetters = Pointcuts.and(foo, setters);
Pointcut allTogether = Pointcuts.and(fooAndSetters, somethingElse);

Regards,
Rod

Fw: [Springframework-developer] Re: AOP API

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

From an earlier exchange we really should have sent to the list...

>> = Bob
> = Rod
----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: "Bob Lee" <cra...@cr...>
Cc: "renaud" <re...@ao...>
Sent: Saturday, November 08, 2003 5:23 PM
Subject: Re: [Springframework-developer] Re: AOP API


> Bob,
>
> > 1) The introduction interceptor implementation and what interfaces it
> > should implement should be separate, hence IntroductionAdvice. Perhaps
> > your interceptor could implement any interfaces. Or, the user may just
> > want to use a subset of the interfaces you can handle. The point is
> > that this logic doesn't need to be built into your interceptor
> > implementation (as it is in IntroductionInterceptor).
>
> Yes, I understand what you mean now. I think you're right.
>
> > 2) The AspectJ terminology kind of smells to me. It was very daunting
> > when I was first exposed to it. "Pointcut, WTF?" Also, I fear that the
> > use of the terminology is imposing AspectJ's design on our own. I know
> > for a fact no one else on my team has any idea what a "pointcut" is.
> > Perhaps "mapper" or "query" would be a better term. My thought is that
> > "mapping servlet filters" or the "query pattern" (PoEAA) may be more
> > familiar concepts than AspectJ.  Do you see this as an issue?
>
> I don't think it's very intuitive terminology either. But I think the
> industry is stuck with it. I think it would be a mistake to reinvent it at
> this stage.
>
> > 3) I don't know about the inheritance scheme with the
> > pointcuts/designators below. My goal is to be able to use any method
> > pointcuts with any class pointcuts. If the method pointcut inherits
> > class pointcut functionality, it makes this more difficult.
> > I also want to be able to combine pointcuts. For example, I'd have an
> > AndClassPointcut that would take two other class pointcuts. I could use
> > one to match a package name and another to determine instanceof.
>
> I agree combinations of pointcuts are useful. I envisaged having a static
> convenience methods for this like
>
> static Pointcut and(Pointcut a, Pointcut b);
>
> To me there should be a single pointcut object (however it's created) that
> can tell me all I need to know about which joinpoints a piece of advice
> should apply to.
>
>
> > 4) I really like that you can implement introductions using an
> > interceptor (I felt weird about it at first). This makes lazy-loading,
> > etc. very clean.
> >
> > What I don't like about the current design is
> > IntroductionInterceptor.getIntroducedInterfaces(). I guess it's because
> > the ProxyFactory has special knowledge of this one subinterface and it
> > magically adds the interfaces.
>
> Yes, I have always been a little uncomfortable with this. So you suggest
> moving the magic to an Advice class, which would still need to be treated
> specially? I do take the argument that a specific advice might only use
that
> interceptor to expose a subset of the possible interfaces it could
support.
> Also that one could implement _any_ interface, although that mightn't
> coexist happily with interceptors further down the chain :-)
>
> Perhaps there's still an argument for a getSupportedInterfaces() method on
> an IntroductionInterceptor interface to enable it to ensure correct usage.
> Otherwise, what's to tell someone that they've added an introduction for
> Foobar interface with a SomethingElseInterceptor that won't help to
> implement Foobar? There would be a no such method error if the invocation
> ever got to a target.
>
> > This is one of the reasons for the separate InterceptionAdvice and
> > IntroductionAdvice, the other being that IntroductionAdvice needs a
> > class designator and InterceptionAdvice needs both class and method
> > designators.
> >
> > 5) I think we should remove AttributeRegistry. The JSR is finalized now
> > and I don't think we need to worry about abstracting attributes in
> > aopalliance. Also, passing it to the pointcut shouldn't be necessary.
>
> I guess this is a fair point. We are planning to provide a metadata
> abstraction in Spring. I'm not convinced that JSR-175 is the whole
metadata
> solution because there's just one source of metadata--the class file (via
> the reflection API). It's nice to be able to override some metadata at
> deploy time if necessary. Also, how long before we get to see 1.5 and how
> long before we get to use it on real projects?
>
> However, I guess there's an argument for moving the metadata stuff down to
> interceptor level, since no one else has ever really believed it should be
> in AOP Alliance. Renaud, what do you think?
>
> > 6) I need a generic factory that I can pass any object to and get the
> > proxied version back. Is this where the BeanPostProcessor comes in? I
> > see myself using the new pointcuts to map the interceptors to these
> > objects.
>
> A BeanPostProcessor registered with a bean factory can automatically proxy
> any object it wants. Configuring this stuff could be pretty cool with the
> post processor: just include Advice objects in the bean factory and a
> modification of an existing post processor for the new API could create
> proxies as necessary for objects affected by the advice.
>
> Regards,
> Rod
>

[Springframework-developer] Re: Re: AOP API

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

Rod

If IntroductionAdvice getInterfaces() method is to return the same as the
IntroductionInterceptor getIntroducedInterfaces() does at present, then
whichever interface this method ends up on, I would like to suggest a
variation on this scheme...

The key thing about these interfaces returned by getIntroducedInterfaces(),
is that they are actually the set of interfaces that are 'implemented' by
the introduction interceptor.  As such I don't think they should be showing
up in an IntroductionAdvice, which is effectively providing a conditional
'declaration' for an extended proxy class.

In the current implementation, there is no distinction between Declared
interfaces and Implemented interfaces.  If such a distinction is introduced,
I think it could offer opportunities for enhancing the ways in which Proxy's
can be composed.

Specifically, an introduction could distinguish between a single 'declared
interface' for which it contracts to provide an implementation, and the set
of 'implemented interfaces' that it actually delivers in the process.

In other words, an IntroductionInterceptor could effectively define methods:

    Class getDeclaredInterface()
    Class[] getImplementedInterfaces()

and a ProxyConfig, could provide a corresponding distinction:

    Class[] getDeclaredInterfaces()
    Class[] getImplementedInterfaces()

where the 'declared interfaces' are the ones that are actually implemented
directly by the target class.

Once an introduction can be tied to a single declared interface, it then
becomes possible to setup an IntroductionFactoryBean that can satisfy that
individual interface.  Indeed, the name of the interface can also then be
used to identify and reference an instance of introduction factory bean.

Now the xml bean config file can be used to bind these
IntroductionFactoryBean implementations both to Interceptor names & to
Interface names.

Then, it becomes possible to provide ProxyFactoryBean definitions looking
like:

<!-- Simple target -->
<bean id="employee" class="org.springframework.beans.Employee">
  <property name="name"><value>name of employee</value></property>
</bean>

<!-- Simple Introduction -->
<bean id="testIntro1" class="org.springframework.beans.TestBean">
    <property name="name"><value>name of testIntro1</value></property>
</bean>

<!-- IntroductionFactoryBean -->
<bean id="testIFB1"
    class="org.springframework.aop.framework.IntroductionFactoryBean">
    <property name="interfaceName">
        <value>org.springframework.beans.ITestBean</value></property>
    <property name="interceptorNames"><value>testIntro1</value></property>
    <property name="singleton"><value>false</value></property>
</bean>

<!-- Convenient 'Interface' Name for this IntroductionFactoryBean -->
<bean id="org.springframework.beans.ITestBean"
    parent="testIFB1">
</bean>

<!-- ProxyFactoryBean using the named Interceptor /
IntroductionFactoryBean -->
<bean id="testPFB1"
    class="org.springframework.aop.framework.ProxyFactoryBean">
    <property name="interceptorNames">
        <value>testIFB1,employee</value></property>
</bean>

<!-- ProxyFactoryBean using the named Interface /
IntroductionFactoryBean -->
<bean id="testPFB2"
    class="org.springframework.aop.framework.ProxyFactoryBean">
    <property name="proxyInterfaces">
        <value>org.springframework.beans.ITestBean</value></property>
    <property name="interceptorNames"><value>employee</value></property>
</bean>

Note the significant thing about the above example is that the 2
ProxyFactoryBeans will produce identical proxy instances, and they will
actually use the same IntroductionFactoryBean - but one is matching the
reference to a proxy Interface, while the other is matching a reference to
an Interceptor.

From a programmatic point of view, the link between Declared Interfaces and
IntroductionFactoryBeans, can also be exploited to dynamically re-implement
a Proxy instance - ie. using code that looks something like:

public class DynamicProxyFactory implements BeanFactoryAware {

 // given an existing proxy instance, construct and return a new one
 // that retains the old target and introduction instances, and adds
 // new introductions for the requested interface.
 Object addInterface(Object proxy, Class intf)

 // given an existing proxy instance, construct and return a new one
 // that retains the old target and those introduction instances other than
 // the one that is to be removed.  If the removed interface is actually
 // declared on the target, then it can be masked by suppressing
 // corresponding set of implemented interfaces
 Object removeInterface(Object proxy, Class intf)

 // as above for but for all the requested additional interfaces
 Object addAllInterfaces(Object proxy, Class[] interfaces)

 // as above for but for all the requested removed interfaces
 Object removeAllInterfaces(Object proxy, Class[] interfaces)

 // given an existing proxy instance, construct and return a new one
 // that retains the old target instance and those introduction instances
 // that provide the requested interfaces.  If any of the interfaces not to
 // retained is actually declared on the target, then it will be masked by
 // suppressing corresponding set of implemented interfaces
 Object retainAllInterfaces(Object proxy, Class[] interfaces)

 // given an existing proxy instance, construct and return a new one
 // that implements declared interfaces.  The new proxy will retain
 // the old target instance, and any of the old introduction instances
 // that match the requested interfaces.  Any requested interfaces that
 // were not 'declared' on the old ProxyConfig, will be satisfied using
 // IntroductionFactoryBean's that have been defined for those
 // interface names.
 Object cast(Object proxy, Class[] interfaces);

}

etc. etc.

I'm sure you get the general idea - simply put, if an Introduction remembers
to actually declare the interface that it 'defines', then you can use
IntroductionFactoryBeans to drive the composition of Proxy's against those
'declared' interfaces.

Now, in the context of the original question about how to define an
IntroductionAdvice, this would suggest that the 'duplication' of a
getDeclaredInterface(), would actually be appropriate. ie:

IntroductionAdvice {
        getInterceptor();
        getDeclaredInterface();
        getClassPointcut();
}

Then a list of IntoductionAdvice's that returned null from getInterceptor(),
would implicitly define an abstract set of mixins - and once the
interceptors were bound, the set would become concrete etc.

From this point, it then becomes a very short step, to allowing the
introduction interceptors to have their own interceptor chains.  Then a
mixin becomes a truly composable unit of reuse !

Apologies for the length of this...

Roger


"Rod Johnson" <rod...@in...> wrote in message
news:1fd801c3a608$ce0fff90$3800a8c0@chopin...
> Roger,
>
> The IntroductionAdvice getInterfaces() method would return the same as the
> IntroductionInterceptor getIntroducedInterfaces() method.
>
> So to avoid the duplication, perhaps the IntroductionAdvice methods should
> be:
>
> getIntroductionInterceptor(); // Can get interfaces from this
>
> get[Class]Pointcut();
>
>
> I don't know whether we need an  IntroductionAdvice at all. It does make
> sense in that introduction isn't method level, but besides that what does
it
> add?
>
> Renaud, should we consider moving the Spring IntroductionInterceptor to
the
> AOP Alliance intercept package? This seems pretty generic, and not at all
> Spring-specific.
>
> Regarding Renaud's point about pointcuts, perhaps another way would be for
> there to be the following pointcut interfaces, and a total of 3 methods:
>
> interface Pointcut {
>
>     // Class filtering for any pointcut
>     boolean applies(Class clazz, AttributeRegistry reg);
>
> }
>
> interface MethodPointcut extends Pointcut {
>
>     // Must test this as well for a MethodPointcut
>     applies(Method, Class, AttributeRegistry);
>
> }
>
> interface DynamicMethodPointcut extends MethodPointcut {
>     // same as now, adds knowledge of arguments
>     applies(Method, Class, args, AttributeRegistry);
> }
>
>
> This way an optimization could be to invoke the applies(Class) method on a
> pointcut before considering its use on any class.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "roger holbrook" <apo...@sn...>
> To: <spr...@li...>
> Sent: Saturday, November 08, 2003 2:43 PM
> Subject: [Springframework-developer] Re: AOP API
>
>
> >
> > Hi Rod
> >
> > Can you expand on the IntroductionAdvice ?
> >
> > > And the new IntroductionAdvice could look as Bob suggested:
> > >
> > >     getInterceptor();
> > >     getInterfaces();
> > >     getClassPointcut();
> > >
> >
> > Does this represent the conditional inclusion of what is currently a
> single
> > IntroductionInterceptor instance into a proxy instance for a given
target
> > class ?
> >
> > I am wondering what the interfaces returned by getInterfaces() represent
> > logically - is this what is currently returned by the method
> > IntroductionInterceptor.getIntroducedInterfaces() or something else ?
> >
> > Roger
> >
> >
> > "Rod Johnson" <rod...@in...> wrote in message
> > news:1f6b01c3a5e1$69ac25a0$3800a8c0@chopin...
> > > 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
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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/
> >
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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/

Re: [Springframework-developer] Excitement and expecting

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

The forum looks good--pity I can't understand 95% of it :-)

Regards,
Rod

----- Original Message ----- 
From: <yan...@ne...>
To: <spr...@li...>
Sent: Saturday, November 08, 2003 5:08 PM
Subject: [Springframework-developer] Excitement and expecting


> I am very excited for your messages,and expect linking it from the Spring
homepage for more fans.
>
>
>
>
> __________________________________________________________________
> McAfee VirusScan Online from the Netscape Network.
> Comprehensive protection for your entire computer. Get your free trial
today!
> http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
>
> Get AOL Instant Messenger 5.1 free of charge.  Download Now!
> http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
>
>
> -------------------------------------------------------
> 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] Excitement and expecting

[<yan...@ne...>]

I am very excited for your messages,and expect linking it from the Spring homepage for more fans.




__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

Re: [Springframework-developer] Welcome anyone

[<yan...@ne...>]

Excuse me,I mean the website provide a platform in order to communication with other Springframework fans with Chinese.
They can share Spring expericece and make the use of Spring more widly in China.

Of course,Welcome anyone who can read Chinese.

http://xglw.51.net/5team/springframework

Now Springframework Chinese Forum is the best professional Spring forum.

"Rod Johnson" <rod...@in...> wrote:

>Good to hear this. Unfortunately I can't read it, but maybe we should
>consider linking to it from the Spring home page for those who can.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: <yan...@ne...>
>To: <spr...@li...>
>Sent: Saturday, November 08, 2003 2:23 PM
>Subject: [Springframework-developer] Welcome anyone
>
>
>> I set up a professional Chinese Spring forum in order to communicate with
>other Spring fans with chinese. I want to provide a site where Chinese can
>share spring framework experience with their home language and make the use
>of spring more widely in China.
>>
>> Now spring framework Chinese Forum is the "only" professional spring forum
>in China. Welcome anyone who can read chinese!
>>
>> http://xglw.51.net/5team/springframework
>>
>>
>> __________________________________________________________________
>> McAfee VirusScan Online from the Netscape Network.
>> Comprehensive protection for your entire computer. Get your free trial
>today!
>> http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
>>
>> Get AOL Instant Messenger 5.1 free of charge.  Download Now!
>> http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
>>
>>
>> -------------------------------------------------------
>> 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
>

__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

Re: [Springframework-developer] Re: AOP API

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

Roger,

The IntroductionAdvice getInterfaces() method would return the same as the
IntroductionInterceptor getIntroducedInterfaces() method.

So to avoid the duplication, perhaps the IntroductionAdvice methods should
be:

getIntroductionInterceptor(); // Can get interfaces from this

get[Class]Pointcut();


I don't know whether we need an  IntroductionAdvice at all. It does make
sense in that introduction isn't method level, but besides that what does it
add?

Renaud, should we consider moving the Spring IntroductionInterceptor to the
AOP Alliance intercept package? This seems pretty generic, and not at all
Spring-specific.

Regarding Renaud's point about pointcuts, perhaps another way would be for
there to be the following pointcut interfaces, and a total of 3 methods:

interface Pointcut {

    // Class filtering for any pointcut
    boolean applies(Class clazz, AttributeRegistry reg);

}

interface MethodPointcut extends Pointcut {

    // Must test this as well for a MethodPointcut
    applies(Method, Class, AttributeRegistry);

}

interface DynamicMethodPointcut extends MethodPointcut {
    // same as now, adds knowledge of arguments
    applies(Method, Class, args, AttributeRegistry);
}


This way an optimization could be to invoke the applies(Class) method on a
pointcut before considering its use on any class.

Regards,
Rod

----- Original Message ----- 
From: "roger holbrook" <apo...@sn...>
To: <spr...@li...>
Sent: Saturday, November 08, 2003 2:43 PM
Subject: [Springframework-developer] Re: AOP API


>
> Hi Rod
>
> Can you expand on the IntroductionAdvice ?
>
> > And the new IntroductionAdvice could look as Bob suggested:
> >
> >     getInterceptor();
> >     getInterfaces();
> >     getClassPointcut();
> >
>
> Does this represent the conditional inclusion of what is currently a
single
> IntroductionInterceptor instance into a proxy instance for a given target
> class ?
>
> I am wondering what the interfaces returned by getInterfaces() represent
> logically - is this what is currently returned by the method
> IntroductionInterceptor.getIntroducedInterfaces() or something else ?
>
> Roger
>
>
> "Rod Johnson" <rod...@in...> wrote in message
> news:1f6b01c3a5e1$69ac25a0$3800a8c0@chopin...
> > 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
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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/
>
>
>
>
>
>
>
> -------------------------------------------------------
> 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...>]

Hi Rod

Can you expand on the IntroductionAdvice ?

> And the new IntroductionAdvice could look as Bob suggested:
>
>     getInterceptor();
>     getInterfaces();
>     getClassPointcut();
>

Does this represent the conditional inclusion of what is currently a single
IntroductionInterceptor instance into a proxy instance for a given target
class ?

I am wondering what the interfaces returned by getInterfaces() represent
logically - is this what is currently returned by the method
IntroductionInterceptor.getIntroducedInterfaces() or something else ?

Roger


"Rod Johnson" <rod...@in...> wrote in message
news:1f6b01c3a5e1$69ac25a0$3800a8c0@chopin...
> 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
> > >
> > >
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> 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] Welcome anyone

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

Good to hear this. Unfortunately I can't read it, but maybe we should
consider linking to it from the Spring home page for those who can.

Regards,
Rod

----- Original Message ----- 
From: <yan...@ne...>
To: <spr...@li...>
Sent: Saturday, November 08, 2003 2:23 PM
Subject: [Springframework-developer] Welcome anyone


> I set up a professional Chinese Spring forum in order to communicate with
other Spring fans with chinese. I want to provide a site where Chinese can
share spring framework experience with their home language and make the use
of spring more widely in China.
>
> Now spring framework Chinese Forum is the "only" professional spring forum
in China. Welcome anyone who can read chinese!
>
> http://xglw.51.net/5team/springframework
>
>
> __________________________________________________________________
> McAfee VirusScan Online from the Netscape Network.
> Comprehensive protection for your entire computer. Get your free trial
today!
> http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
>
> Get AOL Instant Messenger 5.1 free of charge.  Download Now!
> http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
>
>
> -------------------------------------------------------
> 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] Welcome anyone

[<yan...@ne...>]

I set up a professional Chinese Spring forum in order to communicate with other Spring fans with chinese. I want to provide a site where Chinese can share spring framework experience with their home language and make the use of spring more widely in China. 

Now spring framework Chinese Forum is the "only" professional spring forum in China. Welcome anyone who can read chinese! 

http://xglw.51.net/5team/springframework


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

[Springframework-developer] How to use localeResoler

[<yan...@ne...>]

I want to use localeResolver as:
<bean id="localeResolver" class="org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver">
       <property name="local"><value>GB2312</value></property>
</bean>

But how to set the propertys?

I wanted to request Chinese items in html,but I didnot get same character datas.
How to do that can correct the error?


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

[Springframework-developer] How to use localeResolver

[<yan...@ne...>]

I want to use localeResolver as:
<bean id="localeResolver" class="org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver">
        <property name="local"><value>GB2312</value></property>
</bean>

But how to set the propertys?

I wanted to request Chinese items in html,but I didnot get same character datas.
How to do that can correct the error?

__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

RE: [Springframework-developer] AOP API

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

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

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

RE: [Springframework-developer] AOP API

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

Now I think the "disarray" is sorted in my head :-)
+1 for Advice model

Regards,
Dmitriy.

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


> 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




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