I have no actual idea what is going on here….. but…. This looks a lot like the subsystem resolution errors I’ve seen. The subsystem resolver treats some requirements a bit differently than the runtime resolver. For instance, generally bundles are encouraged to specify the services they (might) require with something like effective=actuve. This is ignored at runtime but the subsystem resolver insists on finding a matching capability, i.e. a bundle claiming to supply the service.
Based on this similarity, I wonder if one of the bundles in one of your features has a service requirement that isn’t matched by a declared service capability. For instance, bnd will generate capabilities and requirements for DS services and references, but for other services as far as I know you would need to add the capabilities explicitly. who knows… this might help :-) david jencks > On Sep 13, 2016, at 8:02 PM, oski_bear <[email protected]> wrote: > > Once again, thanks very much for that explanation. I will use that > information to restructure our features. > > Unfortunately, when I applied your fix to our project I ran into another > unexplainable issue. In this scenario, a feature won't install successfully > because it complains about a missing OSGI service even though the service is > clearly there. In fact, if I use the bundle install command to install the > bundle that requires the service it starts up just fine. Here is a link > <https://github.com/damiri-ts/karaf-features-service-issue> > (https://github.com/damiri-ts/karaf-features-service-issue) to the new > project to reproduce this issue. To reproduce: > > 1. mvn clean install > 2. container/target/assembly/bin/karaf clean debug > 3. Not that the example-pki-data-h2 feature did not install: feature:list | > grep -i example-pki-data-h2 > 4. Now try to install the feature manually: feature:install > example-pki-data-h2 - it will complain with the following error: > Error executing command: Unable to resolve root: missing requirement [root] > osgi.identity; osgi.identity=example-pki-data-h2; type=karaf.feature; > version="[2.0.1.SNAPSHOT,2.0.1.SNAPSHOT]"; > filter:="(&(osgi.identity=example-pki-data-h2)(type=karaf.feature)(version>=2.0.1.SNAPSHOT)(version<=2.0.1.SNAPSHOT))" > [caused by: Unable to resolve example-pki-data-h2/2.0.1.SNAPSHOT: missing > requirement [example-pki-data-h2/2.0.1.SNAPSHOT] osgi.identity; > osgi.identity=org.example.pki-data-h2; type=osgi.bundle; > version="[2.0.1.SNAPSHOT,2.0.1.SNAPSHOT]"; resolution:=mandatory [caused by: > Unable to resolve org.example.pki-data-h2/2.0.1.SNAPSHOT: missing > requirement [org.example.pki-data-h2/2.0.1.SNAPSHOT] osgi.service; > effective:=active; > filter:="(&(objectClass=javax.sql.DataSource)(osgi.jndi.service.name=jdbc/pki-data))"]] > > 5. Now to prove that the service it's looking for does actually exist: > "service:list | grep -i jdbc/pki-data" (or something similar) > 6. Now install the bundle specified in the feature manually: install > mvn:org.example/pki-data-h2/2.0.1.SNAPSHOT > 7. And start it: start 216 > > It starts just fine. It's truly baffling. Now I know that the features > definition in this repro project is a mess but believe me, I went back and > took your advice and started restructuring the features files with less > prerequisites and it didn't alleviate any of these problems. I think this is > actually a completely separate unexplained issue but it demonstrates how > installing a bundle with feature:install verses bundle:install somehow ends > up having a completely different outcome. > > Once again thanks for all the support. > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964p4048009.html > Sent from the Karaf - User mailing list archive at Nabble.com.
