[
https://issues.apache.org/jira/browse/FELIX-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14498003#comment-14498003
]
Richard S. Hall commented on FELIX-4854:
----------------------------------------
One other thing, not that this is or isn't part of your difficulty, but we
recommend pretty much never installing the compendium as a bundle.
> Unable to create consistent wiring when same package is exported in same
> version by multiple bundles
> ----------------------------------------------------------------------------------------------------
>
> Key: FELIX-4854
> URL: https://issues.apache.org/jira/browse/FELIX-4854
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-4.6.1
> Reporter: Jens Offenbach
> Priority: Critical
> Labels: framework, resolution, wiring
> Fix For: framework-4.8.0
>
> Attachments: FELIX-4854.zip
>
>
> I am confronted with a strange wiring problem in Felix. Actually I am not
> sure if this is a problem in the Felix or Equinox framework. The attached
> test case shows that there is a differen behaviour in the wiring process
> between Felix 4.6.1 and Equinox 3.10.2.v20150203-1939 when we have different
> bundles with different versions exporting the same package in the same
> version:
> The OSGi specification says:
> The following list defines the preferences, if multiple choices are possible,
> in order of decreasing priority:
> • A resolved exporter must be preferred over an unresolved exporter.
> • An exporter with a higher version is preferred over an exporter with a
> lower version.
> • An exporter with a lower bundle ID is preferred over a bundle with a higher
> ID.
> Let us assume that we have BundleA:1.0.0 and BundleB:2.0.0 both exporting the
> same package in the same version and we have SampleA and SampleB importing
> the package. BundleA gets installed and started, then SampleA. I think
> SampleA gets wired to BundleA:1.0.0. Now BundleB:2.0.0 gets installed and
> started, followed by SampleB. To which bundle must SampleB be wired? Strict
> to the OSGi specification, I would say to BundleB:2.0.0, because it has a
> higher version than BundleA because BundleA and BundleB are both resolved.
> But does it make sense? I think BundleA:1.0.0 should be preferred because it
> is already an active part of the resolution process, but I cannot find
> anything in the specification.
> Can someone please explain me, what is going on in the attached use case. Why
> do we get a different wiring result in Felix 4.6.1 and Equinox
> 3.10.2.v20150203-1939.
> The attached demo use case can be executed via:
> {code}
> mvn clean install -Pfelix
> mvn clean install -Pequinox
> {code}
> Felix 4.6.1:
> {code}
> testWiringA()
> org.apache.felix.osgi.r6.wiring.sampleA uses
> org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
> org.apache.felix.osgi.r6.wiring.sampleB uses
> org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
> testWiringB()
> org.apache.felix.osgi.r6.wiring.sampleA uses
> org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
> org.apache.felix.osgi.r6.wiring.sampleB uses
> org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
> {code}
> Equinox 3.10.2.v20150203-1939:
> {code}
> testWiringA()
> org.apache.felix.osgi.r6.wiring.sampleA uses
> org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
> org.apache.felix.osgi.r6.wiring.sampleB uses
> org.apache.felix.osgi.r6.wiring.bundleB:2.0.0
> testWiringB()
> org.apache.felix.osgi.r6.wiring.sampleA uses
> org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
> org.apache.felix.osgi.r6.wiring.sampleB uses
> org.apache.felix.osgi.r6.wiring.bundleA:1.0.0
> {code}
> The use case is derived from a bigger one resulting in a problematic wiring
> when the OSGi Compendium is installed in version 4.3.1 and version 5.0.0 in
> combination with Felix SCR 1.8.2. In my productive scenario, Felix 4.6.1
> wires my bundles to OSGi Compendium:4.3.1 and Felix SCR to OSGi
> Compendium:5.0.0. In this case Felix SCR gets into trouble during
> introspection, because (based on that wiring) SCR cannot find the activate
> method when it has the ComponentContext class in its signature. Both
> ComponentContext classes are not equal, because they are provided by
> different classloaders.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
