-
Notifications
You must be signed in to change notification settings - Fork 38.5k
Pointcut evaluation fails against AbstractHandlerMethodMapping$MappingRegistry with AspectJ 1.8.10 [SPR-15019] #19586
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
Comments
Juergen Hoeller commented This looks like a regression in AspectJ itself, with an Andy Clement, any insight here? Also, AspectJ 1.8.10 doesn't seem to show up on Maven Central yet... |
Juergen Hoeller commented I've added defensive |
Andy Clement commented Looks like a new diagnostic assert I put into 1.8.10 is firing on something here. So something we were previously silently getting away with. You can add the defensive catch but something weird is going on that is worth getting to the bottom of. Eduard, I don't suppose you have a small testcase that shows this occurring? The Spring Framework tests themselves seem to pass with 1.8.10. (Juergen, I can see it in central -> http://search.maven.org/#artifactdetails%7Corg.aspectj%7Caspectjweaver%7C1.8.10%7Cjar ) |
Juergen Hoeller commented I can see 1.8.10 in Maven Central now as well. Could it have synced that late? Anyway, it's there now... In terms of defensive catching in our Of course, it makes sense to find out about the root cause in any case! |
Juergen Hoeller commented The class that AspectJ chokes on here - |
Eduard Dudar commented Andy, check out this simple project: https://github.com/edudar/aspectj-failure-example. The key there is specific pointcut defined in |
Andy Clement commented Eduard, thanks so much for the fast turnaround on that. I've recreated it with your project. I'll dig deeper.
|
Andy Clement commented I've raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=509327 to cover this in AspectJ. The problem is due to inner types of parameterized types. Whether the inner type is parameterized or not, it still presents itself as parameterized if there is an outer type that is parameterized, this was tripping up some converter code that maps from reflectively resolved types to AspectJ types. Spring uses reflectively discovered types when matching whereas 'regular AspectJ' uses information retrieved directly from the bytecode. We have far fewer tests for the reflective option than the bytecode option. Here, specifically it is the Based on that I distilled Eduards testcode down to a minimal regression test. The question is, now that the diagnostic has served its purpose, should I sort it out and do a quick 1.8.11 including the necessary changes to avoid all those folks on older spring that might trip over it when using 1.8.10. |
Juergen Hoeller commented Andy Clement, a 1.8.11 release certainly wouldn't hurt... but I wouldn't rush it just for this either. Let's rather release it once a bit more feedback came in. After all, most people use specific dependency versions and would first of all have to discover 1.8.10 and choose to upgrade to it. BTW, are there further assertions of this kind in the pointcut matching code path? More specifically, are all other such assertions also throwing |
Eduard Dudar opened SPR-15019 and commented
Two days ago a context in some of our builds stopped starting up. Further investigation led to the fact that AspectJ 1.8.10 was released 2 days ago and our Gradle script picked it up through "1.8.+" dependency. When spring-web is in dependency list the following exception occurs. We use spring-boot but the exception is in core classes thus the ticket here. Rolling back AspectJ 1.8.9 fixes this issue.
Affects: 4.2.8, 4.3.4
Issue Links:
@args
as pointcut, there is case that occur a NPE at calling the unrelated methodBackported to: 4.2.9
The text was updated successfully, but these errors were encountered: