Skip to content

AspectJ execution pointcut does not detect methods in superinterface anymore [SPR-16723] #21264

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue Apr 13, 2018 · 3 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: regression A bug that is also a regression
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Apr 13, 2018

Tiberiu Tofan opened SPR-16723 and commented

After upgrading from Spring Boot 2.0.0.M7 (Sprig AOP 5.0.2) to Spring Boot 2.0.1.RELEASE (Spring AOP 5.0.5) the following advice doesn't work anymore:

@Around("execution(* org.springframework.data.mongodb.repository.MongoRepository.deleteById(..)) && args(id)")

It looks like the pointcut ignores methods that are declared only in a super interface. If I actually override the methods in my MongoRepository, the advice is applied.

A workaround for this is to use the interface where the method is actually declared as a execution pointcut, and specify the target separately:

@Around("target(org.springframework.data.mongodb.repository.MongoRepository) && execution(* org.springframework.data.repository.CrudRepository.deleteById(*)) && args(id)")

Affects: 5.0.5

Issue Links:

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Apr 13, 2018

Juergen Hoeller commented

This turns out to be a side effect of 5.0.5's changes for more efficient proxy treatment: #21216 and more specifically for this issue here #21218. AspectJ is unable to evaluate pointcuts that refer to methods against an interface with the method actually declared on a superinterface... but previously we nevertheless detected them on the concrete class that we were also checking, and that AspectJ introspects fine even for such interface-declared methods. This is still the case for regular classes but not for dynamic interface proxies where we thought we could skip the generated proxy class since it won't reveal any more methods than the interfaces do already... It seems we'll have to re-add that defensive check against the proxy class, even if effectively just needed for AspectJ pointcuts.

So overall, this is quite specific to Spring Data with its runtime-generated interface proxies with a multi-level inheritance hierarchy. I've got a working fix for master and will backport it to 5.0.x ASAP, for release in 5.0.6 in about two weeks (to be picked by Boot 2.0.2 right away).

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

While this regression is rather specific to Spring Data, there is a generally issue uncovered through it: AspectJ pointcut evaluation doesn't understand such subinterface references to methods on superinterfaces if they are not redeclared further down the hierarchy (e.g. on a subinterface or on the concrete class). This involves dynamic proxies with interface inheritance (like in the case above which worked in older versions as a side effect) but also Java 8 default methods on interfaces for regular bean classes (which never worked with such pointcuts).

For 5.0.6, I'm trying to address the underlying issue rather than reverting the optimization that caused the immediate regression in 5.0.5.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

I've pushed my revision for 5.1 and 5.0.6. Please give an upcoming 5.1.0.BUILD-SNAPSHOT or 5.0.6.BUILD-SNAPSHOT a try and let me know whether it works for you...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: regression A bug that is also a regression
Projects
None yet
Development

No branches or pull requests

2 participants