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

[Flavia Rainone (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBREFLECT-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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.




> All ClassLoaders created during tests must have a hard reference on them to avoid gc
> ------------------------------------------------------------------------------------
>
>                 Key: JBREFLECT-81
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-81
>             Project: JBoss Reflection
>          Issue Type: Task
>          Components: Class Pool
>    Affects Versions: JBossReflection.2.0.2.GA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: JBossReflection.2.2.0-Alpha
>
>
> 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.

-- 
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