Karaf verfügen installieren Anforderung osgi.service fehlt aber es ist da

Question

ich eine Datenquelle Funktion haben, die eine Datenquelle als OSGi Service exportiert:

> 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 

Im Rahmen der ds-Funktion, die diese Datenquelle-Dienst erstellt und registriert es enthält auch einen Ping-ds-Bundle, das ich die Datenquelle testen kann:

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

ich habe einen Plan Bündel, das verwendet diese Datenquelle:

<?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> 

Wenn ich eine feature:install foo-datasource-test-feature mache, erhalte ich einen Fehler, den Datenquellenservice nicht finden zu können - aber sein dort und ich kann es gerade gut mit meinem ping-ds cmd erreichen.

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))"]] 

Es scheint, beschweren sich, dass es nicht die OSGi-Service der Datenquelle finden, das installiert wird:

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

Was seltsam ist, neben der Tatsache, dass der Ping-ds Kommando I funktioniert gut geschrieben, Ist das, wenn ich gerade das Testbündel installiere, das in der Funktion ist, über die es klagt, es funktioniert gut. Dies bedeutet, dass dies ein Problem mit dem Feature ist: Installationsprozess selbst.

In der foo-Datenquelle-Test-Funktion Funktion, schließe ich eine foo-Core-Funktion, die die ds-Funktion verweist:

foo-Datenquelle-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> 

Würde dies ein Problem verursachen? Wenn ja, da die foo-Datenquelle-Test-Funktion von dem Datenquellen-Service abhängt, der bereits installiert wird, wie würde dann diese Abhängigkeit in meinen Funktionen beschrieben?

Verwendung:

Karaf Version 4.0.6

Camel-Version 2.16.5

UPDATE

bemerkte ich aus dem Hinweis auf die Funktion Kern, so dass nur das Bündel in die war Test-Funktion und es klagt immer noch. Das hat also nichts mit der Eigenschaft zu tun, Abhängigkeiten aufzuweisen.

Ich werde Karaf Version 4.1.0 versuchen.

UPDATE

Keine Freude am 4.1.0. Als Randnotiz hatte noch mehr Probleme, da ActiveMQ-Client 5.14.4 noch nicht gebaut ist.

Answer 1

Offenbar war feature:install auf der Suche nach dem Dienst nicht in der OSGi Service Registry, sondern in einem MANIFEST woanders.Ein Kollege hat mich an den MANIFEST-Dateien suchen, und ich bemerkte in der foo-Datenquelle-Test, dass es einen Import-Service-Header hatte darin MANIFEST-Datei ist:

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

Es schien wie der Fehler war, denn es war zu tun, was meine MANIFEST-Datei verlangte - nämlich den Dienst zu importieren. Warum es in der OSGi-Service-Registry nicht gefunden wurde, weiß ich nicht. Aber es gab keinen entsprechenden Export-Service in MANIFEST-Dateien. Da aber der Import-Service und der Export-Service offensichtlich veraltet sind und mein älterer Code, der auf Sicherung läuft, nicht auf Karaf migriert wurde, habe ich mich entschieden, einfach einen Weg zu finden, um Import- oder Export- Serviceheader

Nach this advice, fügte ich

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

in die Anweisungen Teil der Maven-Bundle-Plugin in meiner foo-Core-Funktion pom.xml (man erinnere mich, dass foo-Datenquelle-Test-Funktion auf foo abhing -Core-Funktion):

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

Nach mvn clean deploy, die feature:install gearbeitet, und es lief ganz gut (die Datenquelle gefunden, verwendet es und kehrte sQL-Ergebnismenge).

Wie üblich, nach dem Suchen nach einer langen Zeit, war es etwas einfaches oder einfach. Ich bin mir nicht sicher, warum die feature:install sowieso nicht nur die OSGi-Registrierung überprüfen würde, aber es gibt wahrscheinlich einen guten Grund dafür (ich hoffe), dass sie sich nicht darauf verlässt und nach einem MANIFEST-Header sucht. Nicht sicher, ob der Header Provide-Capability in diesem Szenario besser funktioniert, aber das könnte ein Versuch sein.