Community
Participate
Working Groups
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.
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.
fix to reference type delegate and tests included under fix for 116229, patch for harness not yet applied.
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.
