Re: [Springframework-developer] AOP API proposal

[Colin S. <col...@ex...>]

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