The Karaf features service is somewhat similar to the subsystem service.
So yes, the Import-Service is used by the features service to resolve the
bundles that need to be installed.
Removing the Import-Service header is one way to solve the problem.
Another one would be to include the Provide-Capability in the feature along
with the configuration for the datasource instead of using an external
file. The assembly builder supports that well.
<feature name="example-pki-data-h2-all" version="${project.version}"
description="example H2 Persistence">
<feature dependency="true" prerequisite="true">example-pki-data-pre</feature>
<feature>example-pki-data-h2</feature> <configuration name="
org.ops4j.datasource-pki">
osgi.jdbc.driver.name=H2-pool-xa
databaseName=TruAuthDB
dataSourceName=jdbc/pki-data
url=jdbc:h2:./h2/truauth
user=sa
password=
pool.maxIdle=4
pool.maxTotal=4 </configuration>
<capability>
osgi.service;effective:=active;objectClass=javax.sql.DataSource;
osgi.jndi.service.name=jdbc/pki-data
</capability>
</feature>
2016-09-14 7:01 GMT+02:00 David Jencks <david.a.jen...@gmail.com>:
> Well, I’m glad it helped :-)
>
> The Import-Service and Export-Service have IIUC never been osgi official
> valid properties (at least since R4), so I’m not sure what is looking at
> them or who is installing them. The subsystem stuff I was talking about is
> the subsystem spec, implemented in aries, that uses Provide-Capability and
> Require-Capability headers. I don’t know if karaf includes aries subsystem
> or if you are using it somehow. The subsystem resolution process is
> specified to look at the capabilities and requirements and match them up.
> This is pretty loose match since e.g. DS references often have a target
> filter and the service properties on a service are often configured,
> however if the cap/reqs are specified properly you can be pretty sure that
> if the resolver doesn’t resolve your subsystem won’t work.
>
> what are these services pax installs? You don’t know a priori what the
> service interfaces are? A Provide-Capability for a service with
> effective-active basically means “this bundle might possibly register some
> service with this interface but it might not and who knows what the service
> properties will be”.
>
> thanks
> david jencks
> > On Sep 13, 2016, at 9:50 PM, oski_bear <dariusham...@hotmail.com> wrote:
> >
> > Well that was a brilliant suggestion. When I looked in the bundle
> manifest, I
> > saw an "Import-Service" header that looked suspicious. So I decided to
> > remove it by including <_removeheaders>Import-Service</_removeheaders>
> in
> > the instructions for the maven bundle plugin. E.g.
> >
> > <plugin>
> > <groupId>org.apache.felix</groupId>
> > <artifactId>maven-bundle-plugin</artifactId>
> > <version>${maven-bundle-plugin.version}</version>
> > <extensions>true</extensions>
> > <configuration>
> > <instructions>
> >
> > <Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-
> SymbolicName>
> > <Bundle-Version>${project.
> version}</Bundle-Version>
> > <Embed-Dependency>
> > ...
> > </Embed-Dependency>
> > <Export-Package>
> > </Export-Package>
> > <Import-Package>
> > ...
> > </Import-Package>
> > <_removeheaders>Import-Service</_removeheaders>
> > </instructions>
> > </configuration>
> > </plugin>
> >
> > I am now able to workaround this issue. However, I still contend that it
> is
> > a bug. The reason why the "subsystem resolver" can't find a matching
> > capability is because pax-jdbc-config creates these services dynamically
> > based on the configuration present in the etc directory and therefore
> there
> > is no way it could possibly declare these services in it's bundle
> manifest.
> >
> > It seems to me that the subsystem resolver should not look solely in the
> > available manifests for an "Export-Service" that matches the
> > "Import-Service" - that's a terribly naive way of checking for a
> registered
> > service requirement. Instead, shouldn't the subsystem resolver look for a
> > match by querying all services that are registered with the container?
> >
> >
> >
> > --
> > View this message in context: http://karaf.922171.n3.nabble.
> com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964p4048011.html
> > Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
