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

Karl Leopold commented on FELIX-4716:
-------------------------------------

You're right, that's the best solution since it avoids a rotten compromise 
between being able to run standalone and having a potentially unnecessary 
package-dependencies on OSGi-services.

BTW. I'm still a bit confused if the approach with inlining api classes works. 
Imagine:

Bundle 1: exports and contains org.osgi.service.cm;version="1.3"  and requires 
service org.osgi.service.cm.ConfigurationAdmin 
Bundle 2: exports and contains org.osgi.service.cm;version="1.5"

Bundle 3: imports org.osgi.service.cm;version="[1.0,2)" and registers 
ConfigAdminImpl (which implements org.osgi.service.cm.ConfigurationAdmin)
Bundle 4: imports org.osgi.service.cm;version="[1.0,2)" and want to use 
org.osgi.service.cm.ConfigurationAdmin 

Now, when everything is started, Bundle 3 and 4 would be wired to either Bundle 
1 or 2. If they are started in the given order, Bundle 2 would be preferred, 
cause of the higher package-version. Now, bundle 4 can take the service, 
because it's using the same API-package.
But how can bundle 1 use the service? It's service API interface class is not 
an instance of the one provided by Bundle 3, since both API-classes come from 
different bundles and are defined by different class-loaders.

The question is, I believe that there doesn't exist any ConfigAdmin service or 
whatever for the iPOJO bundle. There is one, but it is incompatible because it 
doesn't implement the API provided by iPOJO but the newer provided by the 
latest config-admin-api bundle...

> Bundle org.apache.felix.ipojo physically contains OSGi API classes
> ------------------------------------------------------------------
>
>                 Key: FELIX-4716
>                 URL: https://issues.apache.org/jira/browse/FELIX-4716
>             Project: Felix
>          Issue Type: Bug
>          Components: iPOJO
>    Affects Versions: ipojo-runtime-1.12.0
>         Environment: ubuntu 14, karaf
>            Reporter: Karl Leopold
>            Assignee: Clement Escoffier
>
> The _org.apache.felix.ipojo_ bundle imports, exports and physically contains 
> interface-classes of packages _org.osgi.services.cm_ and 
> _org.osgi.services.log_, both with version 1.3.
> I'm running ipojo in karaf 3.0.2. There, these osgi-packages also exists, 
> just in another version.
> Sometimes it happens that a bundle of mine, which has a package-dependency on 
> _org.osgi.services.cm_ is bound to the ipojo-version instead of the one of 
> felix/karaf. Now, the bundle is resolved, but the service dependency on the 
> ConfigurationAdmin can never be resolved, because the implementation is 
> incompatible to the imported interface.
> I can fix that, if I play around with the bundle start levels.
> Anyway, I think it's a bug in iPOJO, because it should not inline any OSGi 
> API packages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to