[
https://issues.apache.org/jira/browse/FELIX-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626907#action_12626907
]
Felix Meschberger commented on FELIX-702:
-----------------------------------------
The rules are specified in Section 3.7, Resolving Process, of the Core spec.
In essence this is the list:
Provided more than exporter provides a package matching the Import-Package
specification, the algorithm to select an exporter is:
* A resolved exporter must be preferred over an unresolved exporter
* An exporter with a higher version is preferrred over an exporter with a
lower version
* An exporter with a lower bundle ID is preferred over a bundle with a
higher ID
And I would assume, that the Felix framework adheres to this. The problem in
your case seems to be that the new bundle is installed and all bundle wirings
must go to the new bundle and not the system bundle because of the higher
version number.
The framework itself on the other hand still uses the old packages/classes and
hecne the collision.
A possible solution, might be to export the OSGi libraries provided and used by
the framework itself as bootclass path packages instead of (or inaddition to ?)
regular system.packages. Not sure, though, whether this is really good thing ?
> ClassCastException on BundleActivator when deploying bundle with OBR
> --------------------------------------------------------------------
>
> Key: FELIX-702
> URL: https://issues.apache.org/jira/browse/FELIX-702
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR)
> Reporter: Guillaume Sauthier
>
> I fall on this issue yesterday.
> I was using a Felix compiled with the org.osgi.framework;version=1.3.0 (OSGi
> R4.0), compiled before the R4.1 API were released.
> Then, I updated my working copy of Felix, and I did a mvn install. So I have
> compiled the OSGi R4.1 API and placed it in my ~/.m2/repository.xml (thanks
> to the maven-bundle-plugin).
> Now, what happen on the execution side ?
> I understood (reading some recent mails) that the OBR, if it finds a more
> recent version of a package already installed, will install it.
> Nice behavior, but the core packages (I think the ones that comes from the
> System bundle) should be excluded from the update list.
> At least, I had a problem with the org.osgi.framework package.
> It is exported in version 1.3.0 from the System bundle, but OBR downloaded a
> newer bundle (org.osgi.core:1.2.0) that contains the same package in version
> 1.4.0.
> It is downloaded as a dependency computed by OBR when installing a classic
> bundle (no import requirements on a specific org.osgi.framework version), so
> the primary installed bundle ends up to be linked to the org.osgi.core bundle.
> Finally, when Felix try to activate that bundle, it fails with a
> ClassCastException, because the BundleActivator interface used by the
> starting bundle is from the org.osgi.core ClassLoader and because Felix
> expects the BundleActivator interfaces that comes from the System bundle.
> I know this is really a border case situation, because I updated my felix
> sources at the wrong time and I did not relaunch my Felix gateway to use the
> latest org.osgi.framework package version. But anyway, the bug/issue is there
> ...
> Any idea to solve it ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
