[
https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall resolved FELIX-2479.
------------------------------------
Assignee: Richard S. Hall
Fix Version/s: framework-3.2.0
Resolution: Fixed
I committed a fix for this to trunk. It worked in my local test case, but I
didn't test it on the original test case given my limited understanding of Pax
Exam. Please close if satisfied.
> 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
> Assignee: Richard S. Hall
> Fix For: framework-3.2.0
>
> Attachments: splitpackage.zip
>
>
> 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.
