Re: [Springframework-developer] Revised AOP API proposal

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

This is cleaner. What happens btw if the IntroductionInterceptor can 
handle a subset (as opposed to a superset) of what the Classfilter in 
the IntroductionAdvice says? Just a general failure?


Rod Johnson wrote:

>All,
>
>Here's a variant on the API API which goes down the path initially suggested
>by Renaud with separate class and method designators. Apart from that it's
>much the same: Advice is still almost the same.
>
>The unit of composition is a ClassFilter or MethodMatcher. The new Pointcut
>interface allows for FieldMatchers in the future.
>
>Abstract convenience classes could make it easy to use: for example, the
>RegexpPointcut could continue to implement Pointcut, with no need for the
>application developer to work with a distinct ClassFilter or MethodMatcher.
>I think the only downside of this proposal is ease of use, and convenience
>classes can resolve that.
>
>This also enables IntroductionAdvice to have only a ClassFilter, as Bob
>wanted.
>
>Static methods are still used to "compose" pointcuts and the finer-grained
>units of composition.
>
>Feedback please... This is an important API to get right, and time is
>closing now, as we don't want this to delay M3.
>
>Regards,
>Rod
>  
>
>------------------------------------------------------------------------
>
>
>Revised Spring AOP API proposal. Classes and interfaces are unchanged unless noted. The fundamental implementation strategy won't really need to change at all.
>
>
>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 {
>
>	
>	// Aspect getAspect();
>
>}
>
>
>
>
>Advice usable for method or other interception. Spring will support only method interception:
>
>
>public interface InterceptionAdvice extends Advice {
>
>	Pointcut getPointcut();
>	
>	Interceptor getInterceptor();
>	
>
>}
>
>
>
>Advice for an introduction. I 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 {
>	
>	ClassFilter getClassFilter();	// ******* CHANGED SINCE LAST PROPOSAL
>
>	IntroductionInterceptor getIntroductionInterceptor();
>	
>	Class[] getInterfaces();
>	
>}
>
>We can still share a ClassFilter between an introduction and other advice. But now it's impossible to have an Introduction with method-level pointcut information (which is meaningless and good to rule out).
>
>
>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
>
>Changed to pretty much what Renaud suggested:
>
>
>interface Pointcut {
>
>	// A Class filter only narrows the potential choices, making this known at the time of
>	// proxy creation for potential optimization. It's still necessary to check the MethodMatcher if
>	// a class matches.
>	ClassFilter getClassFilter();
>	
>	MethodMatcher getMethodMatcher();
>	
>	// FieldMatcher getFieldMatcher(); could be added without breaking the whole API
>}
>
>
>See source in attached zip. It even has some comments, although the tests don't all pass and aren't very good. (They will be by the time I commit the changes, though :-)
>
>I think that static methods are still best to handle composition. A Pointcuts class of statics is probably necessary as well as ComposablePointcut, although ComposablePointcut may be useful for expressions such as
>
>ComposablePointcut p = new ComposablePointcut(classFilter);
>p.union(classFilter2).intersection(methodMatcher1).intersection(methodMatcher2);
>
>Associativity is L-R. I think this is sufficient!
>
>(I haven't included any constructors as yet.)
>
>
>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
>
>The AttributeRegistry will NOT 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
>
>  
>