You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by oski_bear <da...@hotmail.com> on 2016/09/11 21:50:19 UTC
Features Core bundle stuck in "Resolved" state
I've already submitted a post on this here
<http://karaf.922171.n3.nabble.com/Inconsisent-behavior-during-Karaf-4-0-5-startup-td4047933.html#a4047934>
. Basically the Apache Karaf Features Core bundle get stuck in a "Resolved"
state.
karaf@root>la | grep -i feature
11 | Resolved | 15 | 4.0.5 | Apache Karaf :: Features :: Core
136 | Active | 26 | 4.0.5 | Apache Karaf :: Deployer ::
Features
141 | Active | 30 | 4.0.5 | Apache Karaf :: Features ::
Command
I have to manually start the bundle in order for remaining features to
continue loading properly. The last log entries that relate to
FeaturesServiceImpl are here:
2016-09-11 14:44:36,195 | INFO | pool-49-thread-1 | FeaturesServiceImpl
| 11 - org.apache.karaf.features.core - 4.0.5 | Stopping bundles:
2016-09-11 14:44:36,195 | INFO | pool-49-thread-1 | FeaturesServiceImpl
| 11 - org.apache.karaf.features.core - 4.0.5 |
org.apache.sshd.core/0.14.0
2016-09-11 14:44:36,227 | INFO | pool-49-thread-1 | FeaturesServiceImpl
| 11 - org.apache.karaf.features.core - 4.0.5 |
org.apache.karaf.features.core/4.0.5
2016-09-11 14:44:36,299 | INFO | pool-49-thread-1 | CommandExtension
| 155 - org.apache.karaf.shell.core - 4.0.5 | Unregistering commands for
bundle
org.apache.karaf.features.command/4.0.5
2016-09-11 14:44:36,363 | INFO | ool-106-thread-2 | CommandExtension
| 155 - org.apache.karaf.shell.core - 4.0.5 | Unregistering commands for
bundle
org.apache.karaf.kar.core/4.0.5
2016-09-11 14:44:36,374 | INFO | ool-145-thread-1 | JettyFactoryImpl
| 220 - org.ops4j.pax.web.pax-web-jetty - 4.2.6 | SPDY not available,
creating
standard ServerConnector for Http
2016-09-11 14:44:36,375 | WARN | pool-38-thread-1 | Activator
| 11 - org.apache.karaf.features.core - 4.0.5 | Error starting activator
java.lang.IllegalStateException: Invalid BundleContext.
at
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)[org.apache.felix.framework-5.4.0.jar:]
at
org.apache.karaf.util.tracker.BaseActivator.registerMBean(BaseActivator.java:290)[11:org.apache.karaf.features.core:4.0.5]
at
org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:264)[11:org.apache.karaf.features.core:4.0.5]
at
org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:233)[11:org.apache.karaf.features.core:4.0.5]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_91]
at
java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_91]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_91]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_91]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_91]
2016-09-11 14:44:36,401 | INFO | ool-145-thread-1 | JettyServerImpl
| 220 - org.ops4j.pax.web.pax-web-jetty - 4.2.6 | Pax Web available at
Any thoughts on what might cause this or how to troubleshoot?
[0.0.0.0]:[8181]
--
View this message in context: http://karaf.922171.n3.nabble.com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Features Core bundle stuck in "Resolved" state
Posted by Guillaume Nodet <gn...@apache.org>.
You clearly overuse the prerequisite="true" flag which causes multiple runs
of the features service.
I'll investigate a bit more, as I think there's a bug in the feature
service in this case, but it would be much more efficient to only use the
prerequisite flag when it's actually needed (mainly when deploying url
handlers).
2016-09-13 5:27 GMT+02:00 oski_bear <da...@hotmail.com>:
> I have created a git repository with a project that reproduces these
> issues.
> You can find it here
> <https://github.com/damiri-ts/karaf-features-core-issue> .
> (https://github.com/damiri-ts/karaf-features-core-issue).
>
> Here are the steps to reproduce.
> 1. Build the project: mvn clean install
> 2. Start the container: container/target/assembly/bin/karaf clean debug
>
> The container will startup but the features core bundle will be stuck in
> the
> "resolved" state. If you start it manually (start 11) all features and
> bundles will load correctly.
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964p4047989.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Features Core bundle stuck in "Resolved" state
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
See my answer to the other thread ;)
Regards
JB
On 24/05/2019 16:52, cooshal wrote:
> Hi:
>
> with availability="optional", I am able to install these bundles with
> "feature:install", but I wanted to add one particular bundle (that uses both
> jdbc and jms as well) as a bootFeature, and again it fails to resolve the
> jms services. Could be because the JMS service has not yet been
> instantiated. But shouldn't the bundle wait for the dependency?
>
> I tried removing Import-Service using
> "<_removeheaders>Import-Service</_removeheaders>". But, this had no effect.
>
> How can I provide a capability to a feature? Should I do it in the feature
> file or the maven bundle plugin?
>
> Regards,
> Cooshal.
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Features Core bundle stuck in "Resolved" state
Posted by cooshal <ku...@gmail.com>.
Hi:
with availability="optional", I am able to install these bundles with
"feature:install", but I wanted to add one particular bundle (that uses both
jdbc and jms as well) as a bootFeature, and again it fails to resolve the
jms services. Could be because the JMS service has not yet been
instantiated. But shouldn't the bundle wait for the dependency?
I tried removing Import-Service using
"<_removeheaders>Import-Service</_removeheaders>". But, this had no effect.
How can I provide a capability to a feature? Should I do it in the feature
file or the maven bundle plugin?
Regards,
Cooshal.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Features Core bundle stuck in "Resolved" state
Posted by cooshal <ku...@gmail.com>.
Hi:
that's what I think as well. If these bundles work when deployed manually
and fail to install while provisioning through features, then I suspect that
something specific has to be configured in the features file.
My feature is plain and simple as:
<feature name="stats-mbean" description="Stats MBEAN" version="1.0.0">
<bundle>file:D:/temp/stats-mbean-1.0.0.jar</bundle>
</feature>
The db and broker services are already running and are available in the
service registry. I am not able to provision this just via features. Totally
strange. I have tried this on numerous fresh karaf instances.
I will check if I have messed up something else (so far I do not see
anything but normal config stuffs).
Regards,
Cooshal.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Features Core bundle stuck in "Resolved" state
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
if the services are there, and the property match, it works for sure ;)
Regards
JB
On 08/05/2019 16:23, cooshal wrote:
> I have two Datasources here. That's why I needed to use the filter. I am
> creating the datasources from "etc/org.ops4j.datasource-*.cfg" config files.
> And it works completely fine this way (if I do it manually). I just wanted
> to provision it through feature files in one-go. So, in the current
> environment, I have two DataSources running, and they are selectively
> consumed by the jndi service names.
>
> I checked service:list javax.sql.DataSource, and it lists two different data
> sources, as I had expected.
>
> Thanks !
>
> Regards,
> Cooshal.
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Features Core bundle stuck in "Resolved" state
Posted by cooshal <ku...@gmail.com>.
I have two Datasources here. That's why I needed to use the filter. I am
creating the datasources from "etc/org.ops4j.datasource-*.cfg" config files.
And it works completely fine this way (if I do it manually). I just wanted
to provision it through feature files in one-go. So, in the current
environment, I have two DataSources running, and they are selectively
consumed by the jndi service names.
I checked service:list javax.sql.DataSource, and it lists two different data
sources, as I had expected.
Thanks !
Regards,
Cooshal.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Features Core bundle stuck in "Resolved" state
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
If you created the datasource with jdbc:ds-create, by default the name
is jdbc/dw-datasource that's why I asked about the name.
You can remove the filter to see if the DataSource is found. If not, I
would recommend to check if you don't other bundles than system that
provide package javax.sql.
Regards
JB
On 08/05/2019 16:09, cooshal wrote:
> yes. I have checked the JNDI names. They are listed there with the ClassName
> "com.zaxxer.hikari.HikariDataSource".
>
> To check if I have a valid connection, I tried out "jdbc:tables
> dw-datasource". This works fine enough.
>
> Some information:
> I am using pax-jdbc here. The service reference is used in the blueprint.
>
> <reference id="dw" interface="javax.sql.DataSource"
> filter="(osgi.jndi.service.name=dw-datasource)" />
>
> If I install this bundle manually (by copying into the deploy folder or via
> bundle:install <path>), it works perfectly fine.
>
> Do I need to treat pax-jdbc connections specially?
>
> Regards,
> Cooshal.
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Features Core bundle stuck in "Resolved" state
Posted by cooshal <ku...@gmail.com>.
yes. I have checked the JNDI names. They are listed there with the ClassName
"com.zaxxer.hikari.HikariDataSource".
To check if I have a valid connection, I tried out "jdbc:tables
dw-datasource". This works fine enough.
Some information:
I am using pax-jdbc here. The service reference is used in the blueprint.
<reference id="dw" interface="javax.sql.DataSource"
filter="(osgi.jndi.service.name=dw-datasource)" />
If I install this bundle manually (by copying into the deploy folder or via
bundle:install <path>), it works perfectly fine.
Do I need to treat pax-jdbc connections specially?
Regards,
Cooshal.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Features Core bundle stuck in "Resolved" state
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yes, the JMS issue looks good.
For the datasource, are you sure about the JNDI name ?
Did you check the actual name with jdbc:ds-list command ?
Regards
JB
On 08/05/2019 15:45, cooshal wrote:
> Hi JB:
>
> thank you for the tip. My bundle requires both jms and jdbc services. I
> guess the jms issue is resolved (I borrowed the jms version appender from
> your commit in Decanter ;) ).
>
> I simply added the following line, and the jms issue is not showing up,
> which could mean that it is resolved:
>
> <Import-Package>
> javax.jms;version="[1,3)", *
> </Import-Package>
>
> Interesting thing is, I have another bundle that depends only on jdbc
> service, and that bundle gets started successfully. While, for this bundle,
> I am getting the error below:
>
> missing requirement for .... osgi.service; effective:=active;
> filter:="(&(objectClass=javax.sql.DataSource)(osgi.jndi.service.name=dw-datasource))"]]
>
> Regards,
> Cooshal.
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Features Core bundle stuck in "Resolved" state
Posted by cooshal <ku...@gmail.com>.
Hi JB:
thank you for the tip. My bundle requires both jms and jdbc services. I
guess the jms issue is resolved (I borrowed the jms version appender from
your commit in Decanter ;) ).
I simply added the following line, and the jms issue is not showing up,
which could mean that it is resolved:
<Import-Package>
javax.jms;version="[1,3)", *
</Import-Package>
Interesting thing is, I have another bundle that depends only on jdbc
service, and that bundle gets started successfully. While, for this bundle,
I am getting the error below:
missing requirement for .... osgi.service; effective:=active;
filter:="(&(objectClass=javax.sql.DataSource)(osgi.jndi.service.name=dw-datasource))"]]
Regards,
Cooshal.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Features Core bundle stuck in "Resolved" state
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
I would recommend to check the javax.jms import package ;)
Pax JMS uses JMS 2.0 package. If your bundle uses JMS 1.1, even if the
ConnectionFactory service is available, as they are not from the same
package, it won't work.
I fixed similar issue in Decanter JMS last week.
Regards
JB
On 08/05/2019 14:50, cooshal wrote:
> Hi:
>
> although this post is quite old, was there a definite solution to this
> problem?
>
> My problem is similar, such that my bundle requires the osgi service (I got
> this while trying to do feature:install ... )
>
> osgi.service; effective:=active;
> filter:="(&(objectClass=javax.jms.ConnectionFactory)(osgi.jndi.service.name=jms/msg.consumer))"]]
>
> The "jms/msg.consumer" is already available in the service registry, and
> these bundles work properly when I deploy them by dropping in the deploy
> folder or install them via bundle:install.
>
> Additionally, I can see this jms/msg.consumer in the service:list
> javax.jms.ConnectionFactory as well. To check, if it is functional, I tried
> jms:browse to browse one of the queues. It works fine enough.
>
> But, I am trying to install this bundle as part of a feature as (provided
> that the broker and db services are pre-installed in this custom karaf
> distribution):
>
> <feature name="custom-stats" description="Stats Bundle" version="1.1.1">
> <bundle>file:D:/temp/stats-bundle.jar</bundle>
> </feature>
>
> Regards,
> Cooshal.
>
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Features Core bundle stuck in "Resolved" state
Posted by cooshal <ku...@gmail.com>.
Hi:
although this post is quite old, was there a definite solution to this
problem?
My problem is similar, such that my bundle requires the osgi service (I got
this while trying to do feature:install ... )
osgi.service; effective:=active;
filter:="(&(objectClass=javax.jms.ConnectionFactory)(osgi.jndi.service.name=jms/msg.consumer))"]]
The "jms/msg.consumer" is already available in the service registry, and
these bundles work properly when I deploy them by dropping in the deploy
folder or install them via bundle:install.
Additionally, I can see this jms/msg.consumer in the service:list
javax.jms.ConnectionFactory as well. To check, if it is functional, I tried
jms:browse to browse one of the queues. It works fine enough.
But, I am trying to install this bundle as part of a feature as (provided
that the broker and db services are pre-installed in this custom karaf
distribution):
<feature name="custom-stats" description="Stats Bundle" version="1.1.1">
<bundle>file:D:/temp/stats-bundle.jar</bundle>
</feature>
Regards,
Cooshal.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Features Core bundle stuck in "Resolved" state
Posted by David Jencks <da...@gmail.com>.
Guillaume’s feature example doesn’t look to me like it requires the pax-jdbc-config bundle as a dependency or prerequisite or content (not sure of the correct karaf terminology). However, as long as the pax bundle is installed, it will in fact make that feature provide the datasource(s). This would not be my preferred approach, see below.
The “official” use of service requirement/capabilities expressly and intentionally does not include any service properties such as the jndi name. I would therefore leave it off.
In my opinion the pax-jdbc-config bundle should declare that it provides Datasource and XADatasource services, since it will set these up based on config admin configuration. This is entirely in line with how the service capabilities are supposed to work. For instance, DS services may have configuration policy REQUIRE so they may provide 0….n instances of the service depending on what configurations are present, but they still declare a single capability for the service.
thanks
david jencks
> On Sep 14, 2016, at 7:56 PM, oski_bear <da...@hotmail.com> wrote:
>
> OK but in this case it's actually pax-jdbc-config that is
> providing/registering the service and the feature that I am defining that
> requires the service. Are you proposing that I workaround this problem by
> having the feature that requires the service also declare that it provides
> it as a capability?
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964p4048056.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Features Core bundle stuck in "Resolved" state
Posted by oski_bear <da...@hotmail.com>.
OK but in this case it's actually pax-jdbc-config that is
providing/registering the service and the feature that I am defining that
requires the service. Are you proposing that I workaround this problem by
having the feature that requires the service also declare that it provides
it as a capability?
--
View this message in context: http://karaf.922171.n3.nabble.com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964p4048056.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Features Core bundle stuck in "Resolved" state
Posted by Guillaume Nodet <gn...@apache.org>.
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 <da...@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 <da...@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: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Features Core bundle stuck in "Resolved" state
Posted by David Jencks <da...@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 <da...@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.
Re: Features Core bundle stuck in "Resolved" state
Posted by oski_bear <da...@hotmail.com>.
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.
Re: Features Core bundle stuck in "Resolved" state
Posted by David Jencks <da...@gmail.com>.
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 <da...@hotmail.com> 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.
Re: Features Core bundle stuck in "Resolved" state
Posted by oski_bear <da...@hotmail.com>.
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.
Re: Features Core bundle stuck in "Resolved" state
Posted by Guillaume Nodet <gn...@apache.org>.
You basically have 3 ways to express a dependency on a feature (discarding
the versioning stuff)
<feature dependency="true">xxx</feature>
<feature>xxx</feature>
<feature prerequisite="true">xxx</feature>
The first one means the resolver may include the given feature to solve a
constraint, but this is not a requirement. For example, the constraint may
be solved by a different feature which is already installed. It's similar
to <bundle dependency="true">. An example would be if you want to allow
different providers for a given service. It's not used a lot yet in 4.0.x
but it will be much more leveraged in 4.1.x. A real example is pax-web
6.0, which defines a pax-http feature with a reference to pax-http-jetty
feature with a dependency="true" flag : this allow the user to install
either "pax-http", in which case, the jetty provider will also be
installed, or "pax-http" + "pax-http-tomcat", in which case, the
"pax-http-jetty" feature won't be installed because the provider is already
provided by the "pax-http-tomcat" feature.
In 4.1.x, this will be the case when multiple providers can be chosen :
pax-web, pax-cdi, transaction manager, jpa provider, etc..
The second form is the most basic way : the listed feature will be
installed at the same time. Keep in mind that with karaf 4, features are
not installed one at a time anymore. The feature service use the OSGi
resolver and the set of features to install (or other generic requirements)
and computes the list of bundles to install. With this way, the two
features will be installed at the same time.
The last form (prerequisite="true") is provided in order to actually have
the two features installed one at a time. This is usually not needed. The
only real time it is needed is when the feature service need the dependency
in order to be able to resolve the main feature. For example is the main
feature use the "wrap" url handler for a bundle, the resolver needs the url
handler to be available to download the bundles so that the osgi resolver
can be run. This is really the only real use case I have in mind for the
prerequisite="true" flag. The effect of this flag is that the feature
service will first install any prerequisites, start the feature, and then
do a second pass.
2016-09-13 17:15 GMT+02:00 oski_bear <da...@hotmail.com>:
> Hi Guillame,
>
> Firstly, thanks for looking into this. In regard to the "overuse of the
> prerequisite flag", keep in mind that the project I checked in is
> completely
> artificial. Before checking in the project, I removed many references to
> bundles that are not in the public maven central repository from the
> feature
> definitions so that you could reproduce the issue.
>
> However, it is possible that I am still overusing the prerequisite flag,
> and
> in that case can you please explain to me what the objective criteria are
> for using the prerequisite flag?
>
> I assumed that if a feature has bundles which depend on bundles provided by
> another feature then I should use the prerequisite flag. For example, camel
> needs jline and jline is provided by the shell feature so why shouldn't
> camel mention "shell" as a prerequisite?
>
> Alternatively, can you show exactly where in the project there are
> redundant
> uses of the prerequisite flag and explain why it is redundant so that I
> don't make the same mistake again?
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964p4047998.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Features Core bundle stuck in "Resolved" state
Posted by oski_bear <da...@hotmail.com>.
Hi Guillame,
Firstly, thanks for looking into this. In regard to the "overuse of the
prerequisite flag", keep in mind that the project I checked in is completely
artificial. Before checking in the project, I removed many references to
bundles that are not in the public maven central repository from the feature
definitions so that you could reproduce the issue.
However, it is possible that I am still overusing the prerequisite flag, and
in that case can you please explain to me what the objective criteria are
for using the prerequisite flag?
I assumed that if a feature has bundles which depend on bundles provided by
another feature then I should use the prerequisite flag. For example, camel
needs jline and jline is provided by the shell feature so why shouldn't
camel mention "shell" as a prerequisite?
Alternatively, can you show exactly where in the project there are redundant
uses of the prerequisite flag and explain why it is redundant so that I
don't make the same mistake again?
--
View this message in context: http://karaf.922171.n3.nabble.com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964p4047998.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Features Core bundle stuck in "Resolved" state
Posted by Guillaume Nodet <gn...@apache.org>.
I've raised a JIRA https://issues.apache.org/jira/browse/KARAF-4710
and I'll commit the fix I've found asap.
2016-09-13 5:27 GMT+02:00 oski_bear <da...@hotmail.com>:
> I have created a git repository with a project that reproduces these
> issues.
> You can find it here
> <https://github.com/damiri-ts/karaf-features-core-issue> .
> (https://github.com/damiri-ts/karaf-features-core-issue).
>
> Here are the steps to reproduce.
> 1. Build the project: mvn clean install
> 2. Start the container: container/target/assembly/bin/karaf clean debug
>
> The container will startup but the features core bundle will be stuck in
> the
> "resolved" state. If you start it manually (start 11) all features and
> bundles will load correctly.
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964p4047989.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Features Core bundle stuck in "Resolved" state
Posted by oski_bear <da...@hotmail.com>.
I have created a git repository with a project that reproduces these issues.
You can find it here
<https://github.com/damiri-ts/karaf-features-core-issue> .
(https://github.com/damiri-ts/karaf-features-core-issue).
Here are the steps to reproduce.
1. Build the project: mvn clean install
2. Start the container: container/target/assembly/bin/karaf clean debug
The container will startup but the features core bundle will be stuck in the
"resolved" state. If you start it manually (start 11) all features and
bundles will load correctly.
--
View this message in context: http://karaf.922171.n3.nabble.com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964p4047989.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Features Core bundle stuck in "Resolved" state
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
Do you have your own custom distribution or does it happen with Karaf
vanilla distro ?
I guess you have your custom distro with Pax Web as a boot feature. Can
you share your boot features ?
Thanks
Regards
JB
On 09/11/2016 11:50 PM, oski_bear wrote:
> I've already submitted a post on this here
> <http://karaf.922171.n3.nabble.com/Inconsisent-behavior-during-Karaf-4-0-5-startup-td4047933.html#a4047934>
> . Basically the Apache Karaf Features Core bundle get stuck in a "Resolved"
> state.
>
> karaf@root>la | grep -i feature
> 11 | Resolved | 15 | 4.0.5 | Apache Karaf :: Features :: Core
> 136 | Active | 26 | 4.0.5 | Apache Karaf :: Deployer ::
> Features
> 141 | Active | 30 | 4.0.5 | Apache Karaf :: Features ::
> Command
>
> I have to manually start the bundle in order for remaining features to
> continue loading properly. The last log entries that relate to
> FeaturesServiceImpl are here:
>
> 2016-09-11 14:44:36,195 | INFO | pool-49-thread-1 | FeaturesServiceImpl
> | 11 - org.apache.karaf.features.core - 4.0.5 | Stopping bundles:
> 2016-09-11 14:44:36,195 | INFO | pool-49-thread-1 | FeaturesServiceImpl
> | 11 - org.apache.karaf.features.core - 4.0.5 |
> org.apache.sshd.core/0.14.0
> 2016-09-11 14:44:36,227 | INFO | pool-49-thread-1 | FeaturesServiceImpl
> | 11 - org.apache.karaf.features.core - 4.0.5 |
> org.apache.karaf.features.core/4.0.5
> 2016-09-11 14:44:36,299 | INFO | pool-49-thread-1 | CommandExtension
> | 155 - org.apache.karaf.shell.core - 4.0.5 | Unregistering commands for
> bundle
> org.apache.karaf.features.command/4.0.5
> 2016-09-11 14:44:36,363 | INFO | ool-106-thread-2 | CommandExtension
> | 155 - org.apache.karaf.shell.core - 4.0.5 | Unregistering commands for
> bundle
> org.apache.karaf.kar.core/4.0.5
> 2016-09-11 14:44:36,374 | INFO | ool-145-thread-1 | JettyFactoryImpl
> | 220 - org.ops4j.pax.web.pax-web-jetty - 4.2.6 | SPDY not available,
> creating
> standard ServerConnector for Http
> 2016-09-11 14:44:36,375 | WARN | pool-38-thread-1 | Activator
> | 11 - org.apache.karaf.features.core - 4.0.5 | Error starting activator
> java.lang.IllegalStateException: Invalid BundleContext.
> at
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.karaf.util.tracker.BaseActivator.registerMBean(BaseActivator.java:290)[11:org.apache.karaf.features.core:4.0.5]
> at
> org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:264)[11:org.apache.karaf.features.core:4.0.5]
> at
> org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:233)[11:org.apache.karaf.features.core:4.0.5]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_91]
> at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_91]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_91]
> 2016-09-11 14:44:36,401 | INFO | ool-145-thread-1 | JettyServerImpl
> | 220 - org.ops4j.pax.web.pax-web-jetty - 4.2.6 | Pax Web available at
>
> Any thoughts on what might cause this or how to troubleshoot?
> [0.0.0.0]:[8181]
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofr
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com