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.
