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