[
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602951#action_12602951
]
Daniel Stucky commented on TUSCANY-2343:
----------------------------------------
Hi Rajini,
as suggested I debugged the Equinox code and found out different behavior in
class org.eclipse.osgi.framework.internal.core.BundleLoader#findResource(String
name, boolean checkParent).
The 1st call does not find a PackageSource, so it falls back to
findLocalResource() which locates the class.
The 2nd call finds a PackageSource via method findImportedSource(pkgName), as
this time org.apache.xerces is in the list of imports. It does not contain the
desired class. No fallback logic is executed but null is returned.
Here are some details
1st call:
findImportedSource(pkgName);
imports = {com.ctc.wstx.dtd ->
org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1",
com.ctc.wstx.stax -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1;
bundle-version="3.2.1", com.ctc.wstx.io ->
org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1",
org.codehaus.stax2.validation ->
org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1",
com.ctc.wstx.ent -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1;
bundle-version="3.2.1", org.codehaus.stax2.io ->
org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1",
com.ctc.wstx.util -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1;
bundle-version="3.2.1", com.ctc.wstx.sr ->
org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1",
com.ctc.wstx.sw -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1;
bundle-version="3.2.1", org.codehaus.stax2 ->
org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1",
com.ctc.wstx.exc -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1;
bundle-version="3.2.1", com.ctc.wstx.compat ->
org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1",
com.ctc.wstx.sax -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1;
bundle-version="3.2.1", com.ctc.wstx.evt ->
org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1",
com.ctc.wstx.cfg -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1;
bundle-version="3.2.1", org.codehaus.stax2.evt ->
org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1",
com.ctc.wstx.msv -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1;
bundle-version="3.2.1", com.ctc.wstx.dom ->
org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1",
com.ctc.wstx.api -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1;
bundle-version="3.2.1"}
-> source=null
findRequiredSource(pkgName);
-> source=null
findLocalResource(name);
-> result =
bundleresource://27/META-INF/services/javax.xml.stream.XMLInputFactory
2nd call:
findImportedSource(pkgName);
imports = {javax.xml.stream.events ->
org.apache.tuscany.sca.3rdparty.stax-api-1.0.1; bundle-version="1.0.1",
javax.xml.stream.util -> org.apache.tuscany.sca.3rdparty.stax-api-1.0.1;
bundle-version="1.0.1", org.apache.log4j ->
org.apache.tuscany.sca.3rdparty.log4j-1.2.12; bundle-version="1.2.12",
javax.xml.stream -> org.apache.tuscany.sca.3rdparty.stax-api-1.0.1;
bundle-version="1.0.1", META-INF.services -> org.apache.xerces;
bundle-version="2.9.0"}
-> source = META-INF.services -> org.apache.xerces; bundle-version="2.9.0"
-> result = null
So the questions are:
- why is the list of imports different ?
- is there a bug in the execution logic of
org.eclipse.osgi.framework.internal.core.BundleLoader#findResource(String name,
boolean checkParent). The search is terminated, as the comment "// 3) found
import source terminate search at the source" clearly says. Perhaps it should
continue the search nothing is found ?
Bye,
Daniel
> OSGi bundle design leads to class loading issues
> ------------------------------------------------
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
> Issue Type: Bug
> Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions.
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class
> loading concept.
> Please tell if you see a way, how we could support you by achieving this
> goal. (If a solution is interesting for you) We are willing to contribute
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know
> which version to take.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
