Regarding the Interceptor documentation?

[vickyk]

Hi All,

/**
* Interceptor to wrap a MethodBeforeAdvice. In future we may also offer a more
* efficient alternative solution in cases where there is no interception advice
* and therefore no need to create a MethodInvocation object.
*
* <p>Used internally by the AOP framework: application developers should not need
* to use this class directly.
*
* @author Rod Johnson
* @version $Id: MethodBeforeAdviceInterceptor.java,v 1.3 2004/04/01 15:35:47 jhoeller Exp $
*/
final class MethodBeforeAdviceInterceptor implements MethodInterceptor {

Refferring to above quote what does the following statement mean , I can't understand the concept of removal of interception layer in Proxybased AOP .

In future we may also offer a more
* efficient alternative solution in cases where there is no interception advice
* and therefore no need to create a MethodInvocation object.

Regards
Vicky

[Rod Johnson]

Vicky

I think the comment is pretty explicit. While there will still be a proxy, if there are no MethodInterceptors (only MethodBeforeAdvice and the like) there is no need to create a MethodInvocation object, hence there may be an efficiency gain.

Rgds
Rod

[vickyk]

Vicky

I think the comment is pretty explicit. While there will still be a proxy, if there are no MethodInterceptors (only MethodBeforeAdvice and the like) there is no need to create a MethodInvocation object, hence there may be an efficiency gain.

Rgds
Rod

Rod
I can't think of such a usage where you just have a Advice without the Invocation .Anyway the user will be making the call on the AOP proxy and will expect call to be made at the actual implementation . Now under what circumstances we are making the assumption that the user knows the call will just call a Advice and not the invocation ?

Regards
Vicky

[Rod Johnson]

I can't think of such a usage where you just have a Advice without the Invocation .Anyway the user will be making the call on the AOP proxy and will expect call to be made at the actual implementation . Now under what circumstances we are making the assumption that the user knows the call will just call a Advice and not the invocation ?

Vicky, you've missed the point. The case occurs when there is only MethodBeforeAdvice/ThrowsAdvice etc. and no MethodInterceptors. As far as the caller is concerned it's totally transparent. He/she will just work with the target interface or class.

The MethodInvocation object is necessary only for MethodInterceptors. Look at the signature of MethodBeforeAdvice, for example. It does not need a MethodInvocation, although the present implementation does not attempt the potential optimization I describe in the Javadoc you quoted.

[vickyk]

Vicky

I think the comment is pretty explicit. While there will still be a proxy, if there are no MethodInterceptors (only MethodBeforeAdvice and the like) there is no need to create a MethodInvocation object, hence there may be an efficiency gain.

Rgds
Rod

Does this mean there will be change in the JdkDynamicAopProxy , as that generates the MethodInvocation , which is of type the ReflectiveMethodInvocation ?

Regards
Vicky

[Rod Johnson]

Does this mean there will be change in the JdkDynamicAopProxy , as that generates the MethodInvocation

Yes, both JDK and CGLIB proxies would need to change to accommodate this. But that would be transparent to all application code. It's fairly low priority, but I might consider making this optimization in 1.2.

[robh]

Vicky,

To extend on what Rod is saying, there is much more scope, especially with the Cglib proxy, to improve the performance of all advice types. Theoretically, with Cglib, we can create specific bytecode to handle each kind of advice. The plan first is to have the ability to generate bytecode such that a fixed advice chain can be invoked explicitly by the generated bytecode. After this we can optimize the bytecode for certain advice types such as before advice to invoke the advice and then directly invoke the method, all without the need for reflection.

Rob