Karaf feature install missing requirement osgi.service but it is there

Question

I have a datasource feature that exports a datasource as an OSGi service:

> services -p 2038
OPS4J Pax JDBC Config (2038) provides:
--------------------------------------
objectClass = [org.osgi.service.cm.ManagedServiceFactory]
service.bundleid = 2038
service.id = 211
service.pid = org.ops4j.datasource
service.scope = singleton
----
databaseName = foobar
dataSourceName = fooDatasource
felix.fileinstall.filename = file:/home/foousr/apache-karaf-4.0.6/etc/org.ops4j.datasource-foo.cfg
objectClass = [javax.sql.DataSource]
osgi.jndi.service.name = fooDatasource
service.bundleid = 2038
service.factoryPid = org.ops4j.datasource
service.id = 251
service.pid = org.ops4j.datasource.b3020619-71b9-4876-94c3-477f3e4a503d
service.scope = singleton
url = jdbc:oracle:thin:@dbserver:99999/foo
user = FOOUSR

As part of the ds-feature that creates and registers this datasource service, it also contains a ping-ds bundle that I can use to test the datasource:

> jdbc:ping-ds fooDatasource
Ping from localhost(127.0.0.1) as FOOUSR to schema FOOUSR on dbserver/foo

I have a blueprint bundle that uses that datasource:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:camel="http://camel.apache.org/schema/blueprint"
    xsi:schemaLocation="
       http://www.osgi.org/xmlns/blueprint/v1.0.0
       http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
       http://camel.apache.org/schema/blueprint
       http://camel.apache.org/schema/blueprint/camel-blueprint.xsd
       http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0
       http://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-cm/src/main/resources/org/apache/aries/blueprint/compendium/cm/blueprint-cm-1.1.0.xsd">
    <reference id="ds" interface="javax.sql.DataSource" filter="(dataSourceName=fooDatasource)"/>
    <camelContext id="fooDatasourceTestContext" trace="true" xmlns="http://camel.apache.org/schema/blueprint">
        <route id="fooDatasourceTest">
            <from uri="timer:/fooDatasourceTest?fixedRate=true&amp;repeatCount=1"/>
            <setBody>
                <simple>
                    select * from FOOUSR.FOOTABLE
                </simple>
            </setBody>
            <to uri="jdbc:ds" />
            <to uri="log:fooDatasourceTest?showBody=true"/>
        </route>
    </camelContext>
</blueprint>

When I do a feature:install foo-datasource-test-feature I get an error complaining about not being able to find the datasource service - but its there and I can access it just fine with my ping-ds cmd.

    Error executing command: Unable to resolve root: missing requirement [root] osgi.identity;
 osgi.identity=foo-datasource-test-feature; type=karaf.feature; version="[0.0.1.SNAPSHOT,0.0.1.SNAPSHOT]";
 filter:="(&(osgi.identity=foo-datasource-test-feature)(type=karaf.feature)(version>=0.0.1.SNAPSHOT)(version<=0.0.1.SNAPSHOT))"
 [caused by: Unable to resolve foo-datasource-test-feature/0.0.1.SNAPSHOT: missing requirement
 [foo-datasource-test-feature/0.0.1.SNAPSHOT] osgi.identity; osgi.identity=com.company.project.foo-datasource-test;
 type=osgi.bundle; version="[0.0.1.SNAPSHOT,0.0.1.SNAPSHOT]"; resolution:=mandatory [caused by: Unable to resolve
 com.company.project.foo-datasource-test/0.0.1.SNAPSHOT: missing requirement
 [com.company.project.foo-datasource-test/0.0.1.SNAPSHOT] osgi.service; effective:=active;
 filter:="(&(objectClass=javax.sql.DataSource)(dataSourceName=fooDatasource))"]]

It seems to be complaining that it cannot find the OSGi service's datasource that is installed:

osgi.service; effective:=active;
 filter:="(&(objectClass=javax.sql.DataSource)(dataSourceName=fooDatasource))"]]

What is strange, besides the fact that the ping-ds command I wrote works just fine, is that if I just install the test bundle that's in the feature it complains about, it works just fine. Which means this is some kind of issue with the feature:install process itself.

In the foo-datasource-test-feature feature, I include a foo-core-feature which references the ds-feature:

foo-datasource-test-feature.xml:

<?xml version="1.0" encoding="utf-8"?>
<features name="foo-datasource-test" xmlns="http://karaf.apache.org/xmlns/features/v1.4.0">
    <feature name="foo-datasource-test-feature" version="${project.version}">
        <feature>foo-core-feature</feature>
        <bundle>mvn:com.company.project/foo-datasource-test/${project.version}</bundle>
    </feature>
</features

foo-core-feature.xml:

<?xml version="1.0" encoding="utf-8"?>
<features name="foo-core" xmlns="http://karaf.apache.org/xmlns/features/v1.4.0">
    <feature name="foo-core-feature" version="${project.version}">
        <feature>ds-feature</feature>
        ...
    </feature>
</features>

ds-features.xml:

<?xml version="1.0" encoding="UTF-8"?>
<features name="ds-features" xmlns="http://karaf.apache.org/xmlns/features/v1.0.0">
    <feature name="ds-feature" version="${project.version}" >
        <feature>pax-jdbc-config</feature>
        ...
        <bundle start-level="86">mvn:com.company.commons/foo-datasource/${project.version}</bundle>
    </feature>
    <feature name="ds-ping-datasource" version="${project.version}" >
        <bundle start-level="80">mvn:com.company.commons/foo-ping-datasource/${project.version}</bundle>
        <feature>pax-jdbc-config</feature>
    </feature>
</features>

Would this cause a problem? If so, since the foo-datasource-test-feature depends upon the datasource service already being installed, what would be the proper way to describe this dependency in my features then?

Using:

Karaf version 4.0.6

Camel version 2.16.5

UPDATE

I commented out the reference to the core feature so that just the bundle was in the test feature and it still complains. So this has nothing to do with the feature to feature dependencies.

I am going to try karaf version 4.1.0.

UPDATE

No joy on 4.1.0. As a side note, had even more problems since activemq-client 5.14.4 isn't built yet.

Answer 1

Apparently, feature:install was looking for the service not in the OSGi service registry, but in a MANIFEST somewhere else. A co-worker got me looking at the MANIFEST files and I noticed in the foo-datasource-test that it had an Import-Service header in it's MANIFEST file:

Import-Service: javax.sql.DataSource;multiple:=false;filter=(dataSourceName=fooDatasource)

It seemed like the error was because it was doing what my MANIFEST file was asking it to do - namely to import the service. Why it couldn't find it in the OSGi service registry, I don't know. But there was no corresponding Export-Service in any MANIFEST files. But, since the Import-Service and Export-Service are deprecated apparently and my older code running on fuse that I'm migrating to karaf wasn't informed ;-) I decided to simply find a way to remove any Import- or Export-Service headers.

Following this advice, I added

<_removeheaders>Import-Service,Export-Service</_removeheaders>

into the instructions part of the maven-bundle-plugin in my foo-core-feature pom.xml (recall that foo-datasource-test-feature depended on foo-core-feature):

<build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <version>3.2.0</version>
                <extensions>true</extensions>
                <configuration>
                    <instructions>
                    . . .
                        <Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
                        <Import-Package>*,org.apache.camel.core.osgi</Import-Package>
                        <_removeheaders>Import-Service,Export-Service</_removeheaders>
                    </instructions>
                </configuration>
            </plugin>
        <plugins>
</build>

After mvn clean deploy, the feature:install worked, and it ran just fine (found the datasource, used it and returned sql result set).

As usual, after looking for a long period of time, it was something simple or basic. I am not sure why the feature:install wouldn't just check the OSGi registry anyway, but there's probably a good reason (I hope) for it not relying on that and looking for a MANIFEST header. Not sure if the Provide-Capability header operates better in this scenario, but may give that a try.