Order-dependent class loading problem when split packages are occurring. 
-------------------------------------------------------------------------

                 Key: FELIX-2479
                 URL: https://issues.apache.org/jira/browse/FELIX-2479
             Project: Felix
          Issue Type: Bug
          Components: Framework
    Affects Versions: framework-3.0.1
            Reporter: Rick McGuire


This is sort of a complicated scenario, but I've been able to create a 
relatively simple test to recreate this.  See the attachment for the project.  
Note that to get this to run using the 3.0.1 Felix framework version, I needed 
to create a private build of the pax exam trunk with a dependency change to 
also pick up the latest pax runner snapshot version.  

This problem showed up for us with the 3.0.1 release, but also appears to be in 
the 3.1.0-SNAPSHOT release.  The 2.0.5 release does not have the problem and 
equinox also appears to be handling this correctly.  In this scenario, we have 
a bundle with two embedded jar files that also has a Dynamic-Import: * header 
and a Require-Bundle header for another bundle.  One of the embedded jars uses 
the same package name as packages defined in the bundle referenced by the 
Require-Bundle, creating a split package situation.  The test is fairly simple, 
consisting of just a couple of lines: 

        // if this line is commented out, then the second loadClass() call will 
succeed.  If 
        // this load occurs first, then a NoClassDefFound error results on the 
load for TestClass. 
        Class cls1 = 
bundle1.loadClass("org.apache.geronimo.harness.EETestDummy");
        
        Class cls = bundle1.loadClass("org.apache.geronimo.embedded.TestClass");
        // this will force the fields classes to be resolved. 
        cls.getDeclaredFields(); 

When this is run, the cls.getDeclaredFields() call will get a NoClassDefFound 
exception for the class Lorg/apache/geronimo/harness/EETest

That class is defined in one of the embedded jars.  If the load of the 
EETestDummy class is commented out, then the getDeclaredFields() call does not 
throw the exception.  The resolution of the internal EETest class appears to 
depend on whether the imported package gets resolved first.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to