[ https://issues.apache.org/jira/browse/FELIX-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jens Offenbach updated FELIX-4854: ---------------------------------- Priority: Critical (was: Major) > 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)