Thao-Nguyen Do opened SPR-15533 and commented
When @target is used in a PointCut, all beans created in the same context are proxied, although that PointCut does not match those beans.
This bug was already mentioned and according to that ticket also fixed (#6859), but this behavior is still present in later versions of Spring.
In our application context some beans cannot be proxied. These beans cannot be modified, so usage of @target PointCuts breaks our application. However, not using @target is also not possible, as our use case requires Aspects to be applied to all methods of a wide range of classes (including inherited and interface methods). Our desired behavior for aspects could not be implemented with other PointCut definitions.
Affects: 4.3.4
Issue Links:
- #6859 @target() advices beans it should not
1 votes, 4 watchers
Comment From: spring-projects-issues
Frank Scheffler commented
I am experiencing the same problem when using "@target", as compared to "target". In fact, @target cannot be used in even the simplest Spring Boot application, as it tries to proxy all kinds of beans, e.g. configuration classes pulled in by Boot.
In my opinion, Spring's AspectJExpressionPointcut.matches() method, which suggests that it treats Spring beans as non-dynamic with respect to target, @target, et.al, conflicts with the implementation in RuntimeTestWalker.SubtypeSensitiveVarTypeTestVisitor.visit(), which explicitly treats target and @target differently. In fact, when using target in favor of @target, the context ramp-up is fine.
Comment From: spring-projects-issues
Juergen Hoeller commented
Unfortunately this is unlikely to see proper cycles spent on it over the next few months from our end here. If anybody is willing to provide a patch as a starting point, I'm happy to prioritize it...