Menu
▾
▴
springframework-developer
|
From: Rod J. <rod...@in...> - 2003-11-07 12:44:53
|
All,
I've recently been discussing our pointcut API with Bob Lee (of jAdvise, AOP
Alliance and "Bitter EJB").
Bob is currently using Spring AOP and wants the ability to reuse pointcuts
independently of interceptors.
This seems a reasonable thing to do, so I've been wondering whether it's
correct to model a Pointcut as having an interceptor, as Spring AOP
presently does. Perhaps pointcuts should be independent of interceptors, and
there should be a new Aspect type that contains a Pointcut _and_ an
Interceptor. The methods on ProxyConfig could add and remove this new type
(with the Interceptor methods kept for convenience), and it would need to be
hooked up instead of MethodPointcut in bean factories.
Bob suggested that the ProxyConfig methods could take both a Pointcut _and_
an Interceptor, but we really need a single umbrella object for use in bean
factories.
Something like
interface Aspect {
[Method]Pointcut getPointcut();
Interceptor getInterceptor();
}
Perhaps it could be generalized to hold a List of Interceptor, rather than a
single interceptor. As this would complicate the implementation, I'd like
feedback on whether it's really necessary.
Calling such a new object "Advice" would be more AspectJ-like, but I think
Aspect is clearer.
I'm a bit reluctant to change the public API at this stage, but I think this
would be an improvement. A convenient implementation of Aspect could extend
RegexpMethodPointcut, making usage similar to the existing pattern.
Any thoughts? AOP users, would you mind the impact this would have on your
code? (It wouldn't be too difficult to migrate.)
Regards,
Rod
|
|
From: Rod J. <rod...@in...> - 2003-11-08 19:16:24
|
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
|
|
From: Rod J. <rod...@in...> - 2003-11-09 13:10:59
Attachments:
aop.txt
|
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 |
|
From: roger h. <apo...@sn...> - 2003-11-09 14:59:47
|
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
>
|
|
From: Rod J. <rod...@in...> - 2003-11-09 15:31:43
|
Roger,
I'm still not entirely sure I understand what you're driving at.
I think the problem is that I don't quite get the distinction between
"declared" and "implemented" interfaces.
Are declared interfaces those that the IntroductionInterceptor really
implements. (E.g. the case when the DelegatingIntroductionInterceptor uses
itself as delegate?) In that case, can't they be queried using
introspection?
Are "implemented" interfaces the present getIntroducedInterfaces()?
> 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
>
> }
I think there are occasions when we might want to introduce multiple
interfaces, or (in odd cases) interfaces specified in the advice, not the
interceptor. To take a rather contrived example, I might have a
RemoteException interceptor that throws RemoteException on every method call
if the signature has "throws RemoteException", for use in a test
environment. I could introduce this with an advice specifying that the
introduced interfaces should be MyRemoteEjbBusinessInterface, which the
generic test RemoteExceptionIntroductionInterceptor has never heard of.
Would it be possible to do what you want with an abstract implementation of
IntroductionInterceptor (probably a subclass of
DelegatingIntroductionInterceptor), rather than with the core interfaces?
This could enforce a single introduced class and provide a method returning
it.
Regards,
Rod
|
|
From: roger h. <apo...@sn...> - 2003-11-09 17:23:25
|
Rod
Let me try and explain myself more clearly - ever hopeful...
> Are "implemented" interfaces the present getIntroducedInterfaces()?
yes.
The 'declared' interface would be a single interface for which an
introduction interceptor contracts to provide an implementation. The
'implemented' interfaces would be the full set of superinterfaces for the
'declared' one.
What I am after is the mechanism for an IntroductionAdvice and an
IntroductionInterceptor to be able to specify a set of requested interfaces,
by referring to a single type name - this being the 'declared' type - for
which the introduction contracts to supply the implementation.
The point being that many IntroductionInterceptors may have many
'implemented' interfaces in common - in my previous example InterceptorOne
and IntercptorTwo both implemented interfaces Ia and Ib. So by forcing an
IntroductionInterceptor to provide a single 'declared' interface type, that
collects all the interfaces that it actually implements, I am now able to
use that 'single type name', as a selector for an actual instance of an
IntroductionInterceptor - ie i can ask a factory for an interceptor that
declares it will deliver an implementation for the collection of interfaces
named Ib, or Ic, rather than asking for something that can deliver a pair of
super interfaces Ia and Ib, which in this example is actually still an
ambiguous request.
In short, I want to be able to use the name of a single declared 'interface'
to refer to the particular collection of interfaces that is actually being
implemented. For this to happen, the IntroductionInterceptor needs to state
what the 'declared' interface is, and the IntroductionAdvice can then refer
to it.
The sort of use case I have in mind is as follows. If the
IntroductionAdvice were to specify a 'declared' interface, but not an
IntroductionInterceptor, then a bean factory could check whether an
IntroductionFactoryBean was available to match this 'declared' interface
name. If so, then the corresponding IntroductionInterceptor could be
retrieved from the factory bean, and we are in business - we are wiring up
an interceptor chain by suppling requests for 'named interface types', as
opposed to the current 'named interceptors'. Of course, the binding of the
IntroductionFactoryBeans, or the IntroductionInterceptors to the interface
names can be externalised into the bean config file, as usual.
The larger picture is about being able to use the interface names to wire up
the Proxy beans, as well as the interceptor names.
Is this any clearer ?
> I think there are occasions when we might want to introduce multiple
> interfaces, or (in odd cases) interfaces specified in the advice, not the
> interceptor. To take a rather contrived example, I might have a
> RemoteException interceptor that throws RemoteException on every method
call
> if the signature has "throws RemoteException", for use in a test
> environment. I could introduce this with an advice specifying that the
> introduced interfaces should be MyRemoteEjbBusinessInterface, which the
> generic test RemoteExceptionIntroductionInterceptor has never heard of.
Could you please elaborate on this example - it might help to clarify my
understanding of the use cases you envisage ? In particular I don't
understand what you mean by interfaces specified in the advice, not in the
interceptor ? I was imagining that the Advice was declaring precisely the
interfaces that the interceptor should deliver - the point of discussion
being just how these were being named - if it is otherwise - how does it
work - I am definitely gapping, as the americans would say ;)
Have you committed a copy of the code yet - maybe looking at that would help
me understand better ?
Thanks for your patience
Roger
"Rod Johnson" <rod...@in...> wrote in message
news:213d01c3a6d6$8a7fcf70$3800a8c0@chopin...
> Roger,
>
> I'm still not entirely sure I understand what you're driving at.
>
> I think the problem is that I don't quite get the distinction between
> "declared" and "implemented" interfaces.
>
> Are declared interfaces those that the IntroductionInterceptor really
> implements. (E.g. the case when the DelegatingIntroductionInterceptor uses
> itself as delegate?) In that case, can't they be queried using
> introspection?
>
> Are "implemented" interfaces the present getIntroducedInterfaces()?
>
> > 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
> >
> > }
>
> I think there are occasions when we might want to introduce multiple
> interfaces, or (in odd cases) interfaces specified in the advice, not the
> interceptor. To take a rather contrived example, I might have a
> RemoteException interceptor that throws RemoteException on every method
call
> if the signature has "throws RemoteException", for use in a test
> environment. I could introduce this with an advice specifying that the
> introduced interfaces should be MyRemoteEjbBusinessInterface, which the
> generic test RemoteExceptionIntroductionInterceptor has never heard of.
>
> Would it be possible to do what you want with an abstract implementation
of
> IntroductionInterceptor (probably a subclass of
> DelegatingIntroductionInterceptor), rather than with the core interfaces?
> This could enforce a single introduced class and provide a method
returning
> it.
>
> 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/
|
|
From: roger h. <apo...@sn...> - 2003-11-09 18:07:13
|
Hi Rod
Just realised that I failed to answer you previous question...
> Are declared interfaces those that the IntroductionInterceptor really
> implements. (E.g. the case when the DelegatingIntroductionInterceptor uses
> itself as delegate?) In that case, can't they be queried using
> introspection?
Yes - they can.
From the point of view of the public IntroductionInterface the current
method getIntroducedInterfaces() should become redundant under the scheme I
am suggesting - so the interface should become just:
public IntroductionInterceptor extends Interceptor {
Class getDeclaredInterface(); // single declared interface
}
I've obviously been confusing myself with the details of the current
implementation...
More apologies
Roger
"Rod Johnson" <rod...@in...> wrote in message
news:213d01c3a6d6$8a7fcf70$3800a8c0@chopin...
> Roger,
>
> I'm still not entirely sure I understand what you're driving at.
>
> I think the problem is that I don't quite get the distinction between
> "declared" and "implemented" interfaces.
>
> Are declared interfaces those that the IntroductionInterceptor really
> implements. (E.g. the case when the DelegatingIntroductionInterceptor uses
> itself as delegate?) In that case, can't they be queried using
> introspection?
>
> Are "implemented" interfaces the present getIntroducedInterfaces()?
>
> > 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
> >
> > }
>
> I think there are occasions when we might want to introduce multiple
> interfaces, or (in odd cases) interfaces specified in the advice, not the
> interceptor. To take a rather contrived example, I might have a
> RemoteException interceptor that throws RemoteException on every method
call
> if the signature has "throws RemoteException", for use in a test
> environment. I could introduce this with an advice specifying that the
> introduced interfaces should be MyRemoteEjbBusinessInterface, which the
> generic test RemoteExceptionIntroductionInterceptor has never heard of.
>
> Would it be possible to do what you want with an abstract implementation
of
> IntroductionInterceptor (probably a subclass of
> DelegatingIntroductionInterceptor), rather than with the core interfaces?
> This could enforce a single introduced class and provide a method
returning
> it.
>
> 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/
|
|
From: Colin S. <col...@ex...> - 2003-11-09 15:58:23
|
I like this. I've only used the existing apis in some toy applications,
as well as trying out AspectJ, so I can't say I have very much
real-world experience with AOP but this feels pretty usable to me.
W/regards to Bob's (I think) comment about the naming for some of the
stuff, I personally don't have any problem with resuing AspectJ names,
as long as the sematics are actually the same. As long as that's the
case, I think a lot of people can actually benefit if they've used
AspectJ before, or if they've read some of the AspectJ related articles
out there, as they don't have to learn new names for the same things, of
figure out what the differences are.
Regards,
Colin
Rod Johnson wrote:
>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
>
>
>------------------------------------------------------------------------
>
>
>Spring AOP API proposal. Classes and interfaces are unchanged unless noted. The fundamental implementation strategy won't really need to change at all.
>
>I have all AOP tests passing with the following API, so it's technically feasible.
>
>
>1. Advice
>
>An Advice holds a pointcut and interceptor, allowing reuse of both. There are distinct Advice classes for interception and introduction.
>
>
>
>Base class used to hold Pointcut and for inclusion in an Aspect (see 6).
>
>public abstract interface Advice {
>
> Pointcut getPointcut();
>
> // Aspect getAspect();
>
>}
>
>
>
>
>Advice usable for method or other interception. Spring will support only method interception:
>
>
>public interface InterceptionAdvice extends Advice {
>
> Interceptor getInterceptor();
>
>
>}
>
>
>
>Advice for an introduction. I now agree with Bob that this should specify the interfaces it supports, as an introduction interceptor may implement unknown interfaces in some cases, and we want to be able to limit the total set of interfaces exposed according to advice:
>
>
>public interface IntroductionAdvice extends Advice {
>
> IntroductionInterceptor getIntroductionInterceptor();
>
> Class[] getInterfaces();
>
>}
>
>In this proposal, the Pointcut (inherited) should not be a MethodPointcut, but a base class pointcut as Bob suggested. While it would be nice to enforce this, I think the benefits of having a single base Pointcut outweigh it. (E.g. we can share a class pointcut between introduction and other advice).
>
>
>There would be a change on IntroductionInterceptor to allow it to implement other than a fixed set of interfaces:
>
>
>public IntroductionInterceptor extends Interceptor {
>
> boolean implementsInterface(Interface intf);
>
>}
>
>
>
>2. Pointcuts
>
>
>public interface Pointcut {
>
>
> boolean applies(Class targetClass); //, AttributeRegistry attributeRegistry);
>
>}
>
>
>public interface MethodPointcut extends Pointcut {
>
>
> boolean applies(Method method, Class targetClass);//, AttributeRegistry attributeRegistry);
>
>}
>
>
>The following is unchanged from Spring at present except for the addition of a targetClass argument for consistency:
>
>public interface DynamicMethodPointcut extends MethodPointcut {
>
>
> boolean applies(Method method, Class targetClass, Object[] arguments);//, AttributeRegistry attributeRegistry);
>
>}
>
>
>This inheritance hierarchy is merely to simplify pointcut authoring, and provide the ability to exclude pointcuts based on classes, as Bob wanted. A method pointcut's applicability will be checked by invoking the two applies methods, class first; a dynamic method pointcut by invoking the three. This is consistent with the present Spring approach.
>
>
>Pointcut composition will be managed by a class of static methods:
>
>public class Pointcuts {
>
> public static Pointcut and(Pointcut[] pcs);
>
> public static Pointcut and(Pointcut pc1, pc2);
>
>
> // The following methods will shield framework code from the pointcut hierarchy
>
> public static boolean canApply(Pointcut pc, Class clazz);
>
> public static boolean canApply(Pointcut pc, Class clazz, Method m);
>}
>
>
>A PointcutComposerFactoryBean will enable a pointcut to be exposed from a list of Pointcut for convenient use in a BeanFactory.
>
>
>4.ProxyConfig
>
>MethodPointcut replaced by Advice methods.
>
>Eventually Aspect methods may be added (see 6) but this should be backward compatible.
>
>
>
>5. AttributeRegistry
>
>**** TODO
>
>I'm undecided as to whether the AttributeRegistry should be included in pointcut method signatures.
>
>
>
>6. Aspects
>
>An aspect is a higher-level concept that will be introduced in future, and will be backward compatible. There will be new methods on ProxyConfig to handle with Aspects, but none of the Advice functionality will change.
>
>public interface Aspect {
>
> /**
> * @return an array of InterceptionAdvice or IntroductionAdvice
> */
> Advice[] geAdvice();
>
>}
>
>
>7. Convenience classes
>
>Various implementations, including an AbstractPointcutMethodAdvice class that implements MethodPointcut (leaving subclasses to implement the applies(Method,...) method and exposes an Interceptor property. This will provide an easy migration path for current users who have implemented StaticMethodPointut: they can just change to this base class.
>
>Migrating the test suite wasn't very hard, and the implementation changes weren't too bad either.
>
>
|
|
From: Rod J. <rod...@in...> - 2003-11-08 19:59:36
|
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 |
|
From: Colin S. <col...@ex...> - 2003-11-07 13:50:24
|
I'm ok with this. It makes sense, and it will be a lot harder to justify
breaking the API later. My own code that is affected will be pretty easy
to refactor.
Rod Johnson wrote:
>All,
>
>I've recently been discussing our pointcut API with Bob Lee (of jAdvise, AOP
>Alliance and "Bitter EJB").
>
>Bob is currently using Spring AOP and wants the ability to reuse pointcuts
>independently of interceptors.
>
>This seems a reasonable thing to do, so I've been wondering whether it's
>correct to model a Pointcut as having an interceptor, as Spring AOP
>presently does. Perhaps pointcuts should be independent of interceptors, and
>there should be a new Aspect type that contains a Pointcut _and_ an
>Interceptor. The methods on ProxyConfig could add and remove this new type
>(with the Interceptor methods kept for convenience), and it would need to be
>hooked up instead of MethodPointcut in bean factories.
>
>Bob suggested that the ProxyConfig methods could take both a Pointcut _and_
>an Interceptor, but we really need a single umbrella object for use in bean
>factories.
>
>Something like
>
>interface Aspect {
> [Method]Pointcut getPointcut();
> Interceptor getInterceptor();
>}
>
>
>Perhaps it could be generalized to hold a List of Interceptor, rather than a
>single interceptor. As this would complicate the implementation, I'd like
>feedback on whether it's really necessary.
>
>Calling such a new object "Advice" would be more AspectJ-like, but I think
>Aspect is clearer.
>
>I'm a bit reluctant to change the public API at this stage, but I think this
>would be an improvement. A convenient implementation of Aspect could extend
>RegexpMethodPointcut, making usage similar to the existing pattern.
>
>Any thoughts? AOP users, would you mind the impact this would have on your
>code? (It wouldn't be too difficult to migrate.)
>
>Regards,
>Rod
>
>
|
|
From: Rod J. <rod...@in...> - 2003-11-07 14:24:42
|
+1, I think this is our last chance to change public APIs. I really don't
want to do this after M3.
So we need to make sure we get it right.
We could simply provide an "Aspect" that has one pointcut and one
interceptor. Or we could have one pointcut and multiple interceptors (harder
to justify). Or a set of pointcut-interceptor pairs, as Renaud suggested. Or
is there another mechanism of composition we could provide?
Regards,
Rod
----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Cc: "Bob Lee" <cra...@cr...>
Sent: Friday, November 07, 2003 1:50 PM
Subject: Re: [Springframework-developer] AOP API
> I'm ok with this. It makes sense, and it will be a lot harder to justify
> breaking the API later. My own code that is affected will be pretty easy
> to refactor.
>
>
> Rod Johnson wrote:
>
> >All,
> >
> >I've recently been discussing our pointcut API with Bob Lee (of jAdvise,
AOP
> >Alliance and "Bitter EJB").
> >
> >Bob is currently using Spring AOP and wants the ability to reuse
pointcuts
> >independently of interceptors.
> >
> >This seems a reasonable thing to do, so I've been wondering whether it's
> >correct to model a Pointcut as having an interceptor, as Spring AOP
> >presently does. Perhaps pointcuts should be independent of interceptors,
and
> >there should be a new Aspect type that contains a Pointcut _and_ an
> >Interceptor. The methods on ProxyConfig could add and remove this new
type
> >(with the Interceptor methods kept for convenience), and it would need to
be
> >hooked up instead of MethodPointcut in bean factories.
> >
> >Bob suggested that the ProxyConfig methods could take both a Pointcut
_and_
> >an Interceptor, but we really need a single umbrella object for use in
bean
> >factories.
> >
> >Something like
> >
> >interface Aspect {
> > [Method]Pointcut getPointcut();
> > Interceptor getInterceptor();
> >}
> >
> >
> >Perhaps it could be generalized to hold a List of Interceptor, rather
than a
> >single interceptor. As this would complicate the implementation, I'd like
> >feedback on whether it's really necessary.
> >
> >Calling such a new object "Advice" would be more AspectJ-like, but I
think
> >Aspect is clearer.
> >
> >I'm a bit reluctant to change the public API at this stage, but I think
this
> >would be an improvement. A convenient implementation of Aspect could
extend
> >RegexpMethodPointcut, making usage similar to the existing pattern.
> >
> >Any thoughts? AOP users, would you mind the impact this would have on
your
> >code? (It wouldn't be too difficult to migrate.)
> >
> >Regards,
> >Rod
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: roger h. <apo...@sn...> - 2003-11-07 15:45:31
|
I'm not sure about the packaging and naming of Advice and Aspect
functionality, but on the narrower question of Bob's desire to reuse
pointcuts, could you not to just reverse the existing linkage between
pointcuts & interceptors ? ie.
public interface PointcutMethodInterceptor extends MethodInterceptor {
MethodPointcut getMethodPointcut();
}
public interface MethodPointcut {
}
with other pointcut interfaces unchanged - ie StaticMethodPointcut and
DynamicMethodPointcut continue to extend MethodPointcut.
Any MethodInterceptor that does not implement PointcutMethodInterceptor
would implicitly be 'always invoked'.
Would this not fix Bob's problem ?
It would certainly liberate Pointcuts from Interceptors...
Roger
"Rod Johnson" <rod...@in...> wrote in message
news:1d3a01c3a52c$e4a29470$3800a8c0@chopin...
> All,
>
> I've recently been discussing our pointcut API with Bob Lee (of jAdvise,
AOP
> Alliance and "Bitter EJB").
>
> Bob is currently using Spring AOP and wants the ability to reuse pointcuts
> independently of interceptors.
>
> This seems a reasonable thing to do, so I've been wondering whether it's
> correct to model a Pointcut as having an interceptor, as Spring AOP
> presently does. Perhaps pointcuts should be independent of interceptors,
and
> there should be a new Aspect type that contains a Pointcut _and_ an
> Interceptor. The methods on ProxyConfig could add and remove this new type
> (with the Interceptor methods kept for convenience), and it would need to
be
> hooked up instead of MethodPointcut in bean factories.
>
> Bob suggested that the ProxyConfig methods could take both a Pointcut
_and_
> an Interceptor, but we really need a single umbrella object for use in
bean
> factories.
>
> Something like
>
> interface Aspect {
> [Method]Pointcut getPointcut();
> Interceptor getInterceptor();
> }
>
>
> Perhaps it could be generalized to hold a List of Interceptor, rather than
a
> single interceptor. As this would complicate the implementation, I'd like
> feedback on whether it's really necessary.
>
> Calling such a new object "Advice" would be more AspectJ-like, but I
think
> Aspect is clearer.
>
> I'm a bit reluctant to change the public API at this stage, but I think
this
> would be an improvement. A convenient implementation of Aspect could
extend
> RegexpMethodPointcut, making usage similar to the existing pattern.
>
> Any thoughts? AOP users, would you mind the impact this would have on your
> code? (It wouldn't be too difficult to migrate.)
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
|
