You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Rick McGuire (JIRA)" <ji...@apache.org> on 2010/07/20 19:42:52 UTC
[jira] Created: (FELIX-2479) Order-dependent class loading problem
when split packages are occurring.
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.
[jira] Commented: (FELIX-2479) A bundle importing its own exports
doesn't correct expose its exports when required by another bundle
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891237#action_12891237 ]
Richard S. Hall commented on FELIX-2479:
----------------------------------------
Great news. I think we'll try to do another micro release before too long, since we have a good collection of minor bugs already fixed.
> A bundle importing its own exports doesn't correct expose its exports when required by another bundle
> -----------------------------------------------------------------------------------------------------
>
> 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.
[jira] Updated: (FELIX-2479) Required bundles not correctly
re-exporting their substitutable exports
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-2479:
-----------------------------------
Summary: Required bundles not correctly re-exporting their substitutable exports (was: A bundle importing its own exports doesn't correctly expose its exports when required by another bundle)
Even better summary. ;-)
> Required bundles not correctly re-exporting their substitutable exports
> -----------------------------------------------------------------------
>
> 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.
[jira] Updated: (FELIX-2479) Order-dependent class loading problem
when split packages are occurring.
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick McGuire updated FELIX-2479:
--------------------------------
Attachment: splitpackage.zip
If you have a version of PAX exam setup that can handle the 3.0.1 framework, then you should be able to run this by just doing an "mvn install" from the test subproject after unzipping.
> 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
> 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.
[jira] Commented: (FELIX-2479) Order-dependent class loading
problem when split packages are occurring.
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891078#action_12891078 ]
Rick McGuire commented on FELIX-2479:
-------------------------------------
I'd also like to note that your test in gogo is missing the critical final step. The NoClassDefFound error does not occur until the getDeclaredMethods() call is made on TestClass. That's what forces the load of the EETest class that causes the error.
> 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.
[jira] Updated: (FELIX-2479) Required bundles not correctly
re-exporting their substitutable exports
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Pauls updated FELIX-2479:
------------------------------
Fix Version/s: framework-3.0.2
(was: framework-3.2.0)
> Required bundles not correctly re-exporting their substitutable exports
> -----------------------------------------------------------------------
>
> 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.0.2
>
> 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.
[jira] Closed: (FELIX-2479) Order-dependent class loading problem
when split packages are occurring.
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick McGuire closed FELIX-2479.
-------------------------------
There is joy in Mudville! The second attempt fixed the original, more complicated problem too. Thank you for the quick turnaround on this!
> 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.
[jira] Commented: (FELIX-2479) Order-dependent class loading
problem when split packages are occurring.
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890445#action_12890445 ]
Richard S. Hall commented on FELIX-2479:
----------------------------------------
I see what is going on. The bundle being required imports its own packages and there is a bug when calculating the available packages from a required bundle which is essentially ignoring the packages that are also imported, but they should be part of the export signature of the required bundle. This omission causes the second bundle to actually get dynamically wired to the first bundle on the first class load above, which then subsequently short circuits the class loading from that point forward. I think this should be a straightforward fix. I will work on a patch tomorrow.
> 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
> 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.
[jira] Commented: (FELIX-2479) Order-dependent class loading
problem when split packages are occurring.
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890906#action_12890906 ]
Richard S. Hall commented on FELIX-2479:
----------------------------------------
Actually, I think I might know what is going on...I'll investigate more tomorrow and let you know.
> 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.
[jira] Reopened: (FELIX-2479) Order-dependent class loading problem
when split packages are occurring.
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick McGuire reopened FELIX-2479:
---------------------------------
I wasn't able to get the pax runner framework to execute using a fresh build of the framework trunk, but when I retested this in the original failing environment, this same problem still occurs.
I rebuilt the current Felix trunk, which builds a 3.1.0-SNAPSHOT version. I'm a little confused by the fact this Jira is marked as fixed in 3.2.0. Am I picking up the correct build for testing?
I'm not really able to provide you with a copy of the bundles that are causing the problem because these materials are covered by an NDA. I'm willing to do whatever is necessary though to gather information that can help you debug the problem.
> 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.
[jira] Updated: (FELIX-2479) A bundle importing its own exports
doesn't correctly expose its exports when required by another bundle
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-2479:
-----------------------------------
Summary: A bundle importing its own exports doesn't correctly expose its exports when required by another bundle (was: A bundle importing its own exports doesn't correct expose its exports when required by another bundle)
> A bundle importing its own exports doesn't correctly expose its exports when required by another bundle
> -------------------------------------------------------------------------------------------------------
>
> 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.
[jira] Resolved: (FELIX-2479) Order-dependent class loading problem
when split packages are occurring.
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (FELIX-2479) Order-dependent class loading
problem when split packages are occurring.
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (FELIX-2479) Order-dependent class loading problem
when split packages are occurring.
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall resolved FELIX-2479.
------------------------------------
Resolution: Fixed
Ok, I've committed another potential fix that works for me in the supplied test case and in an additional test case I created where the previous patch failed. There was a bug in calculating which packages were exposed from a required bundle when that bundle imports packages it exports. Even if the bundle ends up wiring to a different provider, it must still expose the packages it was exporting (i.e., it implicitly reexports its substituted exports).
Please close this bug if satisfied. 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.
[jira] Commented: (FELIX-2479) Order-dependent class loading
problem when split packages are occurring.
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891139#action_12891139 ]
Richard S. Hall commented on FELIX-2479:
----------------------------------------
True, I missed that, but:
g! c = (bundle 6) loadclass org.apache.geronimo.embedded.TestClass
[ ...big string dump of the loaded class deleted... ]
g! $c getDeclaredMethods
g! $c getName
org.apache.geronimo.embedded.TestClass
g! $c getMethods
public final void java.lang.Object.wait() throws java.lang.InterruptedException
public final native void java.lang.Object.wait(long) throws java.lang.InterruptedException
public final void java.lang.Object.wait(long,int) throws java.lang.InterruptedException
public boolean java.lang.Object.equals(java.lang.Object)
public java.lang.String java.lang.Object.toString()
public native int java.lang.Object.hashCode()
public final native java.lang.Class java.lang.Object.getClass()
public final native void java.lang.Object.notify()
public final native void java.lang.Object.notifyAll()
g!
It still doesn't seem to cause an issue for me with the current test. Regardless, I'll investigate more.
> 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.
[jira] Updated: (FELIX-2479) A bundle importing its own exports
doesn't correct expose its exports when required by another bundle
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-2479:
-----------------------------------
Summary: A bundle importing its own exports doesn't correct expose its exports when required by another bundle (was: Order-dependent class loading problem when split packages are occurring. )
Change the summary to match the real issue.
> A bundle importing its own exports doesn't correct expose its exports when required by another bundle
> -----------------------------------------------------------------------------------------------------
>
> 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.