[ 
https://issues.apache.org/jira/browse/FELIX-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14498002#comment-14498002
 ] 

Richard S. Hall commented on FELIX-4854:
----------------------------------------

I would guess it is due to the fact that Equinox uses a "big bang" approach to 
resolving bundles where it resolves all unresolved bundles every time it 
resolves any, while the Felix framework uses an "incremental" approach where it 
only resolves the bundles necessary to satisfy the required dependencies (e.g., 
of a bundle that is being started or from which a class is being loaded). This 
can definitely lead to different wiring results and is within the spec.

You might be able to test this out if in Gogo you try to resolve all of your 
bundles at once, e.g., "resolve 1 2 3 4 5"...I am pretty sure that causes more 
recent Felix frameworks to resolve them in a single pass (old frameworks [< 
4.0.0] still did it incrementally in this case).

If that's not the issue, then I'm not sure off the top of my head.

> 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)

Reply via email to