Closed
Description
David opened SPR-16677 and commented
As described in this question. Looking forward to your reply ! Best wishes!
Affects: 4.3.10
Reference URL: https://stackoverflow.com/questions/49558599/mix-use-beannameautoproxycreator-and-annotationawareaspectjautoproxycreator-to-p
Issue Links:
- Comprehensively cache annotated methods for interfaces and superclasses [SPR-16675] #21216 Comprehensively cache annotated methods for interfaces and superclasses
- AspectJ execution pointcut does not detect methods in superinterface anymore [SPR-16723] #21264 AspectJ execution pointcut does not detect methods in superinterface anymore
- AopUtils.getMostSpecificMethod should expose dynamic proxy class methods [SPR-16757] #21298 AopUtils.getMostSpecificMethod should expose dynamic proxy class methods
- AspectJ annotation pointcuts fail to evaluate against interface-based proxies [SPR-16803] #21343 AspectJ annotation pointcuts fail to evaluate against interface-based proxies
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
No branches or pull requests
Activity
spring-projects-issues commentedon Apr 2, 2018
Juergen Hoeller commented
Do the #21216 changes make a difference for your scenario already, as long as you're using CGLIB proxies? You could try the latest
5.0.5.BUILD-SNAPSHOT
to find out.The user class enforcement in
AopUtils
was primarily motivated by runtime-generated configuration classes and not by proxies...but might help for proxy scenarios as well. And if it does help there, we should indeed consider interface-based double-proxying scenarios as well.spring-projects-issues commentedon Apr 3, 2018
Juergen Hoeller commented
I've resolved this through ignoring proxy classes in
AopUtils.getMostSpecificMethod
, always returning a user-level method handle there. This same change also goes nicely with #21216, allowing it to expose the actual target class toMethodMatcher
implementations still... just iterating over the user-class methods right away in order to avoid the superclass traversal.As for double-proxying with interface proxies, this is generally a much tougher issue since semantically the inner proxy needs to expose the corresponding metadata to the next level... and AspectJ annotation pointcuts do not really support interface-based matching to begin with. I recommend the use of target-class proxies for such scenarios for the time being.
spring-projects-issues commentedon Apr 3, 2018
David commented
Thanks for your reply! I can't get the latest 5.0.5.BUILD-SNAPSHOT in maven repo to find out. So I have reviewed the commit . As for my scenario ( double-proxying the target class), I found the crucial code
If the targetClass is a proxy class generated by CGLIB, then you will use the user class to find the bridged method. So if the annotation is present in the target class (implementation not the interface), the BeanNameAutoProxyCreator and AnnotationAwareAspectJAutoProxyCreator can work together (event thought we can not decide the execution order of the two aspect ).
Thanks for your excellent work!