I thought so, it is for OBR. It is not enabled in Karaf 2.3.4 by default. Was there any reason? I have copied the both jars in Karafs system directory and added the both lines at the end of Karafs startup.priperties - I can't install jndi too. Is it a bug in the OBR resolver? Is this problem known in Karaf?

Krzysztof Sobkowiak
added a comment - 09/Apr/14 05:18 I thought so, it is for OBR. It is not enabled in Karaf 2.3.4 by default. Was there any reason? I have copied the both jars in Karafs system directory and added the both lines at the end of Karafs startup.priperties - I can't install jndi too. Is it a bug in the OBR resolver? Is this problem known in Karaf?

We install the OBR features resolver support to avoid duplicate bundle versions when dealing with the different features descriptors. E.g. is Camel has version x of a bundle and CXF has bundle y, the OBR support kind of irons out these inconsistencies.

Gert Vanthienen
added a comment - 09/Apr/14 09:23 We install the OBR features resolver support to avoid duplicate bundle versions when dealing with the different features descriptors. E.g. is Camel has version x of a bundle and CXF has bundle y, the OBR support kind of irons out these inconsistencies.
The reason we enabled the obr feature like this instead of adding it to the boot features, was to work around https://issues.apache.org/jira/browse/KARAF-608 .

Gert Vanthienen
added a comment - 09/Apr/14 09:31 The problem with the jndi feature probably is that the Aries Proxy bundle does not have an Export-Service header to advertise it's publishing that service into the OSGi Service Registry.

We can add obr into the boot features, but we have problem with KARAF-608

We can remove the obr resolver from startup.properties, but we have problem with duplicate bundle versions

We could eventually overwrite the jndi feature in ServiceMix features and add obr as dependency. Even if Aries adds the Export-Service header, it will be probably not included in ServiceMix 5. In ServiceMix 6 the problem is solved by KARAF-608

Krzysztof Sobkowiak
added a comment - 09/Apr/14 10:30 Should we open a JIRA issue in Aries?
As workaround we have 3 solutions
We can propose to install the obr feature manually.
We can add obr into the boot features, but we have problem with KARAF-608
We can remove the obr resolver from startup.properties , but we have problem with duplicate bundle versions
We could eventually overwrite the jndi feature in ServiceMix features and add obr as dependency. Even if Aries adds the Export-Service header, it will be probably not included in ServiceMix 5. In ServiceMix 6 the problem is solved by KARAF-608

It looks like changing the start level of org.apache.felix.bundlerepository in assembly/src/main/filtered-resources/startup-obr.properties from 10 to 30 (similar to the start level defined by the obr feature) solves the problem

Krzysztof Sobkowiak
added a comment - 16/Apr/14 21:28 - edited It looks like changing the start level of org.apache.felix.bundlerepository in assembly/src/main/filtered-resources/startup-obr.properties from 10 to 30 (similar to the start level defined by the obr feature) solves the problem
# enabling features OBR resolver support
org/apache/felix/org.apache.felix.bundlerepository/${felix.obr.version}/org.apache.felix.bundlerepository-${felix.obr.version}.jar=30
org/apache/karaf/features/org.apache.karaf.features.obr/${karaf.version}/org.apache.karaf.features.obr-${karaf.version}.jar=30

It took me some debugging yesterday eventing to figure out why the change in startlevel in the startup.properties file actually works. It turns out that for the bundles that are already active in the container when the OBR implementation is installed, it looks at the actual services that have been published by a bundle instead of relying on the Export-Service header for this information.

Anyway, changing the startlevel to anything higher than the proxy-impl bundle will do the trick, so I think that would be the best solution for this issue until the ARIES-1182 one gets fixed.

Gert Vanthienen
added a comment - 02/May/14 19:49 - edited It took me some debugging yesterday eventing to figure out why the change in startlevel in the startup.properties file actually works. It turns out that for the bundles that are already active in the container when the OBR implementation is installed, it looks at the actual services that have been published by a bundle instead of relying on the Export-Service header for this information.
Anyway, changing the startlevel to anything higher than the proxy-impl bundle will do the trick, so I think that would be the best solution for this issue until the ARIES-1182 one gets fixed.

So we can do the change as workaround until ARIES-1182 is fixed. Next we can revert this change for ServiceMix 5.x. If I have correctly understood KARAF-608, we can completely remove the obr bundles from startup.properties in ServiceMix 6.x (after migration to Karaf 3.x) and add obr in featuresBoot.

Krzysztof Sobkowiak
added a comment - 02/May/14 20:23 So we can do the change as workaround until ARIES-1182 is fixed. Next we can revert this change for ServiceMix 5.x. If I have correctly understood KARAF-608 , we can completely remove the obr bundles from startup.properties in ServiceMix 6.x (after migration to Karaf 3.x) and add obr in featuresBoot .