[
https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890872#action_12890872
]
Richard S. Hall commented on FELIX-2479:
----------------------------------------
For the framework, we work on odd/even minor numbers for development/release
builds. So the 3.1.0-SNAPSHOT release will become 3.2.0 when released (or
possibly a 3.0.x release if we do a quick bug fix release, since we don't do
branches).
I forgot that I got your attached example working directly in Gogo without the
need for Pax Exam, so this is what I see when I run it with trunk:
g! lb
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (3.1.0.SNAPSHOT)
1|Active | 1|Apache Felix Bundle Repository (1.6.2)
2|Active | 1|Apache Felix Gogo Command (0.6.0)
3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
4|Active | 1|Apache Felix Gogo Shell (0.6.0)
5|Installed | 1|Required test harness bundle (1.0.0.SNAPSHOT)
6|Installed | 1|Bundle used to load failing class (1.0.0.SNAPSHOT)
g! (bundle 6) loadclass org.apache.geronimo.harness.EETestDummy
DEBUG: WIRE: [6.0] module; (bundle-symbolic-name=org.apache.geronimo.harness)
-> [5.0]
[ ...big string dump of the loaded class deleted... ]
g! (bundle 6) loadclass org.apache.geronimo.embedded.TestClass
[ ...big string dump of the loaded class deleted... ]
So you can see that I load the first class, which causes the bundles to get
resolved, then I load the second class. So the attached test case appears to
work correctly. You can make sure you see the same thing locally by following
the same steps. If you see something different, then you don't have the right
build.
If you see the same thing, but your real scenario still doesn't work, then it
must not be the same issue as the attached test case. I guess that means you'll
need another go at creating an example scenario to demonstrate the issue.
Thanks.
> 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.
