-
I found
MethodAfterAdviceInterceptor
implementsAfterAdvice
, so i thinkMethodBeforeAdviceInterceptor
also should implementsBeforeAdvice
to indicate that is a BeforeAdvice. -
Recently when i search spring source code, i found when
ThrowsAdviceInterceptor
is constructed, it just found methods which name isafterThrowing
and last param is ThrowableSubclass; but sometimes developer may be disorder the 4 param due to careless(eg: afterThrowing( Object[] args, Method method, Object target, ServletException ex) ), now the error only can be found when exception occur, i think framework should be reminder developer in time, whenThrowsAdviceInterceptor
is constructed, if we find he/she write error, we should tell he/she that error occurs as soon as possible.
Comment From: jhoeller
I've opened SPR-17088 for the MethodBeforeAdviceInterceptor
part since we can easily roll this into 5.1 RC1 still. As for validating reflective signatures, good point but we have other such cases across the framework, so might rather aim for a wider-spread solution.
Comment From: plx927
ok, I will continue to find such case to improve framework and try to find a wider-spread solution, thank you for your encouragement!
Comment From: jhoeller
It's well spotted indeed, thanks for raising it!
As for a wider-spread solution, this is in particular about a common exception type that we would raise in case of an unexpected method signature for a reflectively invoked callback in other parts of the framework. I'm not keen on introducing an exception type just for AOP throws advices there.
Comment From: plx927
I got it. Just now, i found there is an AopConfigException
in aop module, can i exchange AopConfigException
to my custom exception?
Comment From: jhoeller
AopConfigException
sounds fine for this purpose, indeed! Could you rebase your PR against master (picking up the latest round of refinements there) and squash it into a single commit please?
Comment From: plx927
ok, i am doing it!
Comment From: plx927
@jhoeller this pr need add more commit?