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.