felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-702) ClassCastException on BundleActivator when deploying bundle with OBR
Date Fri, 29 Aug 2008 08:36:46 GMT

    [ 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
> 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.

View raw message