[jboss-jira] [JBoss JIRA] Updated: (JBREFLECT-81) All ClassLoaders created during tests must have a hard reference on them to avoid gc

[ https://jira.jboss.org/jira/browse/JBREFLECT-81?page=com.atlassian.jira.p... ] Flavia Rainone updated JBREFLECT-81: ------------------------------------ Description: Otherwise, if the classloader is gc'ed during test execution, the test will fail because the ClassPool will enter an illegal state, for being associated with a null class loader. According to Kabir, RepositoryClassPoolTestCase.testURLChildOfGlobalUcl fails on JDK5/OS X because of this: | public void testURLChildOfGlobalUcl() throws Exception | { | L globalLoader = testScenario.createLoader(new CLDeploymentBuilder("GLOBAL", JAR_A_1)); | L childALoader = createChildURLLoader(globalLoader, JAR_B_1); | | testScenario.loadClass(childALoader, globalLoader, CLASS_A); | testScenario.loadClass(childALoader, CLASS_B); | | L childBLoader = createChildURLLoader(globalLoader, JAR_A_2); | System.out.println("========> G" + globalLoader); | System.out.println("========> A " + childALoader); | System.out.println("========> B " + childBLoader); | testScenario.loadClass(childBLoader, globalLoader, CLASS_A); | } The output shows G and A to always have a classloader, probably because the testScenario call maintains a strong reference to the loader? B sometimes is shown to have null loader, so createChildURLLoader needs to be reworked somehow to maintain a strong reference to the loader. was: According to Kabir, RepositoryClassPoolTestCase.testURLChildOfGlobalUcl fails on JDK5/OS X because of this: | public void testURLChildOfGlobalUcl() throws Exception | { | L globalLoader = testScenario.createLoader(new CLDeploymentBuilder("GLOBAL", JAR_A_1)); | L childALoader = createChildURLLoader(globalLoader, JAR_B_1); | | testScenario.loadClass(childALoader, globalLoader, CLASS_A); | testScenario.loadClass(childALoader, CLASS_B); | | L childBLoader = createChildURLLoader(globalLoader, JAR_A_2); | System.out.println("========> G" + globalLoader); | System.out.println("========> A " + childALoader); | System.out.println("========> B " + childBLoader); | testScenario.loadClass(childBLoader, globalLoader, CLASS_A); | } The output shows G and A to always have a classloader, probably because the testScenario call maintains a strong reference to the loader? B sometimes is shown to have null loader, so createChildURLLoader needs to be reworked somehow to maintain a strong reference to the loader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira