Bug 117885

Summary: Classes are reloaded in AjcTestCase.run() which is confusing, inconsistent and unrepresentative
Product: [Tools] AspectJ Reporter: Matthew Webster <matthew_webster>
Component: CompilerAssignee: aspectj inbox <aspectj-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P5    
Version: DEVELOPMENT   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Patch none

Description Matthew Webster CLA 2005-11-24 06:11:21 EST 
When running an XMLBasedAjcTestCase a new class loader is created with the sandbox on the classpath. This allows testcases to be isolated from each other. It also facilitates load-time weaving (Bug 107741). Unfortunately the URLClassLoader is created with the boot class loader (null) as its parent and all the org.aspectj modules are added to the classpath. This can cause ClassCastExceptions in the harness because there are 2 copies of each AspectJ class in the system, is not consistent with ordinary JUnit testcases which all use the same copy of the classes and is not representative of a runtime environment where it is unlikely the same class loader will be used to load both AspectJ and the user’s application. In fact bug 116229 and bug 116254 were raised because the new PointcutParser and AjTypeSystem interfaces made this assumption.
Comment 1 Matthew Webster CLA 2005-11-24 16:33:52 EST 
Created attachment 30584 [details]
Patch

This approach was introduced in the LTW harness enhancement. It should also speed up running the tests. Also included fix to Java15ReflectionBasedReferenceTypeDelegate and testcase.
Comment 2 Adrian Colyer CLA 2005-11-27 13:40:23 EST 
fix to reference type delegate and tests included under fix for 116229, patch for harness not yet applied.
Comment 3 Matthew Webster CLA 2006-06-15 06:54:28 EDT 
The implementation of AjcTestCase.run() has changed considerably while fixing the Class.forName() problem in Bug 140695. Now a completely new classloader is created for AspectJ each time a test is run. Ideally we should just delegate to the System classloader but it can have the wrong classpath (see http://dev.eclipse.org/mhonarc/lists/aspectj-dev/msg02066.html).

Changes to project dependencies should eventually solve the classpath problem however we also need to deal with misuse of Class.forName(). The sandbox classloader should not delegate requests for weaver classes unless explicitly configured in the test. This could be implemented using an OSGi-style FilteringDelegateClassLoader.