1 Reply Latest reply on Feb 25, 2010 1:32 PM by adrian.brock

    CL requirements and domains not in-synch

    alesj

      From this user discussion

      * http://community.jboss.org/message/527661#527661

      I would expect that our behavior is not OK. Or is this intentional?

       

      I've created a test case which mocks this behavior.

      If this is expected, I'll just "fix" the test to resemble that.

      Otherwise I can dig in, or let you (=Adrian) have a go as a CL maintainer.

      (and since you're already working on that re-package bounce thing )

       

      See HierarchicalDomainUnitTestCase::testExplicitRequirementsInDomain.

        • 1. Re: CL requirements and domains not in-synch

          I assume you mean the commented out test? It looks like it is working as it is supposed to out-of-the-box.

           

          The purpose of Hierarchical domains is to reproduce what was done in JBoss4.x with the Hierarchical loader repositories.

          So by default they work the same way.

           

          The jboss-classloading.xml only lets you specify parent-first=true/false,

          i.e. ParentPolicy.BEFORE or ParentPolicy.AFTER_BUT_JAVA_BEFORE

           

          If you want more control on what is visible in the parent,

          then you need to create the domain manually to specify your filter.

           

          e.g. Your test works if I change it as follows:

           

          [ejort@warjort jboss-cl]$ svn diff classloading/src/test/java/org/jboss/test/classloading/dependency/test/HierarchicalDomainUnitTestCase.java 
          Index: classloading/src/test/java/org/jboss/test/classloading/dependency/test/HierarchicalDomainUnitTestCase.java
          ===================================================================
          --- classloading/src/test/java/org/jboss/test/classloading/dependency/test/HierarchicalDomainUnitTestCase.java     (revision 101491)
          +++ classloading/src/test/java/org/jboss/test/classloading/dependency/test/HierarchicalDomainUnitTestCase.java     (working copy)
          @@ -23,6 +23,7 @@
           
           import junit.framework.Test;
           import org.jboss.classloader.spi.ClassLoaderSystem;
          +import org.jboss.classloader.spi.ParentPolicy;
           import org.jboss.classloading.spi.dependency.policy.mock.MockClassLoadingMetaData;
           import org.jboss.classloading.spi.metadata.ClassLoadingMetaDataFactory;
           import org.jboss.classloading.spi.metadata.ExportAll;
          @@ -478,7 +479,8 @@
           
              public void testExplicitRequirementsInNewDomain() throws Exception
              {
          -      // FIXME - testExplicitRequirementsInDomain("SomeNewDomain");
          +      system.createAndRegisterDomain("SomeNewDomain", ParentPolicy.BEFORE_BUT_JAVA_ONLY, system.getDefaultDomain());
          +      testExplicitRequirementsInDomain("SomeNewDomain");
              }
           
              protected void testExplicitRequirementsInDomain(String domain) throws Exception
          
          

           

          But in that case, there is little point in the hierarchical domain. ;-)    

           

          system.createAndRegisterDomain("SomeNewDomain", ParentPolicy.BEFORE_BUT_JAVA_ONLY);

           

          would give you a new top-level domain and also make your test work.

           

          NOTE: In real life, you would use ParentPolicy.BEFORE in the last example,

          but if you used that in this test, it would load the support classes from the classpath

          rather than the Mock classloader. :-)