Bug 306915 - Classloader issue when pointcut definition and target were loaded by different classloaders
Summary: Classloader issue when pointcut definition and target were loaded by differen...
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: LTWeaving (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 major with 7 votes (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-24 04:39 EDT by Harald Radi CLA
Modified: 2020-02-21 01:31 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Radi CLA 2010-03-24 04:39:39 EDT
Build Identifier: 1.6.8

The pointcut keeps a reference to a world instance that holds the context classloader at the time of creating the pointcut. When that pointcut is later tried to be matched with a class that originates from a different classloader I get "warning can't determine annotations of missing type <classname>
 [Xlint:cantFindType]" although the class instance is already available at that time.

To be more precise this happens in conjunction with the spring framework when having multiple contexts and per context classloaders. I really don't know whom to blame here as the root problem might as well be how spring manages pointcut definitions, but I had an extensive skype chat with Juergen on that and we concluded that this might be easiest fixed in aspectj.

Spring calls PointcutExpression.couldMatchJoinPointsInType(Class aClass) and already passes a valid class instance. PointcutExpressionImpl:80 then tries to reload that class with the classloader of the pointcut definition by calling world.resolve(aClass.getName()) - which obviously fails.

As a workaround i just added

if (matchType instanceof MissingResolvedTypeWithKnownSignature) {
  world = new ReflectionWorld(aClass.getClassLoader());
  matchType = world.resolve(aClass.getName());
}

below that, which worked as a naive quick fix. Nevertheless, I presume you are doing this to avoid keeping references to foreign class instances and their classloaders, so I can't tell the implications of that workaround.

Reproducible: Always

Steps to Reproduce:
1. application context C1 holds a pointcut definition P1 and uses classloader L1 as bean class loader

2. application context C2 is a subcontext of C1 and uses classloader L2 as bean class loader; L2 uses L1 as parent class loader (L2 hence contains a superset of the classes in L1)

3. C2 contains a bean definition for a bean that is only visible to L2 but matches P1 (e.g. a @within pointcut for an annotation visible to L1)
Comment 1 Vivin Paliath CLA 2020-02-19 19:24:56 EST
Has this been fixed in newer versions? I'm running into this exact issue on 1.6.12.
Comment 2 Alexander Kriegisch CLA 2020-02-19 21:21:38 EST
@Vivin: Maybe you should have provided the link to your corresponding StackOverflow question which also contains the information that upgrading to AspectJ 1.8.14 solved the problem for your specific situation:

https://stackoverflow.com/q/60306668/1082681

Having said that, even though I am not 100% sure if your issue really is the same because according to your stacktrace you seem to use Spring AOP rather than AspectJ LTW, it would be nice if a maintainer could check if this has been resolved. Even if Vivin does use Spring AOP, indirectly of course AspectJ is used in order to parse pointcuts and match classes, so there is a chance that this is the same issue.
Comment 3 Alexander Kriegisch CLA 2020-02-19 21:50:28 EST
I looked around in the GitHub clone of the AspectJ source code repository and found that the issue seems to have been addressed on 2015-05-27 by Andy Clement:

https://github.com/eclipse/org.aspectj/blame/V1_9_2/org.aspectj.matcher/src/org/aspectj/weaver/internal/tools/PointcutExpressionImpl.java#L84

The corresponding commit is:

https://github.com/eclipse/org.aspectj/commit/e1f6d1fc52d329b018ed11c08cab5011f267c3d0

Even though the commit was not mean to solve this issue primarily but was rather targeted at lambdas, it seems to have solved this one too. Maybe Andy can retest and verify before closing this issue, then set the AspectJ version for this ticket to 1.6.8 as reported and the resolved version to 1.8.7 as indicated by the Git tags.
Comment 4 Vivin Paliath CLA 2020-02-21 01:31:49 EST
@Alexander thank you for looking into it. I apologize for not updating this with the link to my StackOverflow question. It honestly just slipped my mind. I had been debugging this issue for almost two days and my brain was already frazzled!