IMHO, AbstractAspectJAdvice.invokeAdviceMethod should call ProceedingJoinPoint.proceed() instead of invoking Method.invoke manually. So that it should call the generated byte code in case that CglibAopProxy is used.
Comment From: snicoll
This code invokes before/after advice methods on the aspect, not the target method that is being intercepted. ProceedingJoinPoint.proceed() is for dispatching to that target method, and that's what we use it for.
Comment From: natl-set
@snicoll I think we should use the same mechanism to invoke the proxy code. In cglib aop proxy case, it creates MethodProxy and wrap that in MethodInvocation so it should use that instead of trying to call Method.invoke directly.
Comment From: jhoeller
@natl-set that's the case for invocations on the proxied target object. However, the code pointed out above calls advice methods on separate AspectJ aspect classes that just happen to be part of the advice chain before the call eventually proceeds to the target object. Those aspect classes themselves are not CGLIB-processed, so we can only use regular reflection for those.
Alternatively, if you are concerned about that extra reflective overhead there, you could implement all your advices as a MethodInterceptor where we perform direct invocations through the callback interface. Then there would only be interceptor invocations through that interface plus the eventual ProceedingJoinPoint invocation on the target object.