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.
