Yesterday, when I was finishing up the cleanup of the classpool tests (JBREFLECT-74), I found a test that was being run only on the sanity test case but not on the classpool test.
The new structure of the tests allows using the same test code to test both classpools and classloaders. Hence, the test scenario that was only being run on the sanity test case is now run on the classpool test case as well. And this uncovered a failure. :-(
This is the problematic scenario:
- URLClassLoader associated with b.jar (contains B.class) is the parent of Unified Class Loader A (below)
- UCL A associated with a.jar, is in the global repository
- UCL B, associated with b.jar, is in the global repository
When UCL A is requested to load B.class, it will load the class from the parent URLClassLoader.
The loaded class is put into the classes cache collection, and the pair UCL A, B.class is put in the loaderToClassesMap (both collections belong to the global repository).
During cleanup, UCL A is removed from the repository and, since B.class is mapped by UCL A in the loaderToClassesMap, the B.class is removed from the classes collection.
But on the ClassPoolTestCase, B.class is is associated to the parent URLClassLoader in the loaderToClassesMap collection. As a result, the B.class is not removed from classes collection during cleanup. That B.class in the classes cache is garbage and will cause failure to the next test. The cause of this difference in behavior is that UCL A is registered in the repository as a dynamic class loader*, and this causes an important if statement of LoadMgr3 to be skipped.
My question: is the loaderToClassesMap allowed to contain class loaders that are not in the repository, as in the scenario described?
_________________
* I understand that this will allow the repository to find new classes generated by the ClassPool. During the creation of a JBossUclDelegatingClassPool, a temp file URL is added to the UCL, and the UCL is added to the repository as a dynamic ClassLoader.
