Problem installing cxf WebService
Hi I'm having a problem installing a CXF WebService. I'm getting an unresolved constraint error: starting bundle: file:/C:/Users/kit/apache-karaf-2.3.3/deploy/cxf-code-first-bundle-1.0-SNAPSHOT.jar org.osgi.framework.BundleException: Unresolved constraint in bundle cxf-code-first-bundle [186]: Unable to resolve 186.0: missing requirement [186.0] osgi.wiring.package; ((osgi.wiri ng.package=javax.jws)(version=2.0.0)(!(version=3.0.0))) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1247)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1219)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:508)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)[6:org.apache.felix.fileinstall:3.2.6] I tried several examples on the web, no luck. Thanks for your help Laci
Re: Running command script on startup
Hi Henryk, Check the etc/shell.init.script file as described on http://karaf.apache.org/manual/latest/developers-guide/scripting.html under 'startup'. Kind regards, Richard On Wed, Feb 12, 2014 at 10:37 AM, Henryk Konsek hekon...@gmail.com wrote: Hi, Is there a way to create a script with some Karaf shell commands that will be executed during the container startup? Thank you in advance. Cheers. -- Henryk Konsek http://henryk-konsek.blogspot.com
Re: Running command script on startup
Hi Henryk, With the right OS: echo list | bin/karaf works, though might not be what you’re looking for. Dan. On 12 Feb 2014, at 09:37, Henryk Konsek hekon...@gmail.com wrote: Hi, Is there a way to create a script with some Karaf shell commands that will be executed during the container startup? Thank you in advance. Cheers. -- Henryk Konsek http://henryk-konsek.blogspot.com
question about feature xml file
Hi JB, I want to write my project's feature xml files in order to install bundles easily. Do you have any website resource introducing how to write customized feature xml files? Thank you! -- View this message in context: http://karaf.922171.n3.nabble.com/question-about-feature-xml-file-tp4031629.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Problem installing cxf WebService
Hi, Could you please edit $KARAF_HOME/etc/jre.properties change javax.jws, \ javax.jws.soap, \ to javax.jws;version=2.0, \ javax.jws.soap;version=2.0, \ and cleanly restart karaf? － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat On 2014-2-12, at 下午5:41, Laci Gaspar wrote: Hi I'm having a problem installing a CXF WebService. I'm getting an unresolved constraint error: starting bundle: file:/C:/Users/kit/apache-karaf-2.3.3/deploy/cxf-code-first-bundle-1.0-SNAPSHOT.jar org.osgi.framework.BundleException: Unresolved constraint in bundle cxf-code-first-bundle [186]: Unable to resolve 186.0: missing requirement [186.0] osgi.wiring.package; ((osgi.wiri ng.package=javax.jws)(version=2.0.0)(!(version=3.0.0))) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1247)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1219)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:508)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)[6:org.apache.felix.fileinstall:3.2.6] I tried several examples on the web, no luck. Thanks for your help Laci
Re: Problem installing cxf WebService
Sorry, actually you should install mvn:org.apache.geronimo.specs/geronimo-ws-metadata_2.0_spec/1.1.3 bundle which can export javax.jws 2.0 Btw, I think you should install features.xml from cxf and features:install cxf which will offer you all necessary bundles when you work on cxf related projects － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat On 2014-2-12, at 下午6:58, Freeman Fang wrote: Hi, Could you please edit $KARAF_HOME/etc/jre.properties change javax.jws, \ javax.jws.soap, \ to javax.jws;version=2.0, \ javax.jws.soap;version=2.0, \ and cleanly restart karaf? － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat On 2014-2-12, at 下午5:41, Laci Gaspar wrote: Hi I'm having a problem installing a CXF WebService. I'm getting an unresolved constraint error: starting bundle: file:/C:/Users/kit/apache-karaf-2.3.3/deploy/cxf-code-first-bundle-1.0-SNAPSHOT.jar org.osgi.framework.BundleException: Unresolved constraint in bundle cxf-code-first-bundle [186]: Unable to resolve 186.0: missing requirement [186.0] osgi.wiring.package; ((osgi.wiri ng.package=javax.jws)(version=2.0.0)(!(version=3.0.0))) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1247)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1219)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:508)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)[6:org.apache.felix.fileinstall:3.2.6] I tried several examples on the web, no luck. Thanks for your help Laci
Re: question about feature xml file
Hi, I'm not JB ;) but you'll find a sample at [1]. regards, Achim [1] - https://github.com/ANierbeck/Camel-Pax-Exam-Demo/tree/master/feature 2014-02-12 11:30 GMT+01:00 simafengyun1984 yifeng@citi.com: Hi JB, I want to write my project's feature xml files in order to install bundles easily. Do you have any website resource introducing how to write customized feature xml files? Thank you! -- View this message in context: http://karaf.922171.n3.nabble.com/question-about-feature-xml-file-tp4031629.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/
Re: Karaf Jenkins
I also saw this warning/error: 10:58:35,291 WARN [Start Level Event Dispatcher] Error when installing feature test-dependencies: java.io.IOException: Error resolving artifact org.apache.curator:curator-client:jar:LATEST when provisioning the bundles I changed mavenBundle().groupId(org.apache.curator).artifactId(curator-client), to mavenBundle().groupId(org.apache.curator).artifactId(curator-client).version(2.3.0), and voila all the tests run green on jenkins. next step is to understand why this bundle isnt active. 46 | Resolved | 20 | 1.0.0| Apache Aries Blueprint Core Compatiblity Fragment Bundle, Hosts:4 -- View this message in context: http://karaf.922171.n3.nabble.com/Karaf-Jenkins-tp4031573p4031634.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Karaf Jenkins
Hi, see my comments inline. regards, Achim 2014-02-12 12:27 GMT+01:00 rocket nicholas.martens...@gmail.com: I also saw this warning/error: 10:58:35,291 WARN [Start Level Event Dispatcher] Error when installing feature test-dependencies: java.io.IOException: Error resolving artifact org.apache.curator:curator-client:jar:LATEST when provisioning the bundles I changed mavenBundle().groupId(org.apache.curator).artifactId(curator-client), to mavenBundle().groupId(org.apache.curator).artifactId(curator-client).version(2.3.0), if you didn't define this dependency in your POM and if you didn't run the needed maven plugin depends-maven-plugin it won't work. and voila all the tests run green on jenkins. next step is to understand why this bundle isnt active. 46 | Resolved | 20 | 1.0.0| Apache Aries Blueprint Core Compatiblity Fragment Bundle, Hosts:4 A fragment bundle never is started/active since it's attached to it's host bundle, at this point it's bundle 4 -- View this message in context: http://karaf.922171.n3.nabble.com/Karaf-Jenkins-tp4031573p4031634.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/
Re: Karaf Jenkins
if you didn't define this dependency in your POM and if you didn't run the needed maven plugin depends-maven-plugin it won't work. depends-maven-plugin and curator-client was in the POM all the time the only thing i added was the .version(2.3.0) i dont know if its a bug or a feature but it did work without .version(2.3.0) in karaf 2.3.2 and native container. -- View this message in context: http://karaf.922171.n3.nabble.com/Karaf-Jenkins-tp4031573p4031636.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Problem installing cxf WebService
Thanks for your answer. The problem was in my pom file, which had a dependency to geronimo. I removed that and now it works. Thanks, Laci On 12.02.2014 12:04, Freeman Fang wrote: Sorry, actually you should install mvn:org.apache.geronimo.specs/geronimo-ws-metadata_2.0_spec/1.1.3 bundle which can export javax.jws 2.0 Btw, I think you should install features.xml from cxf and features:install cxf which will offer you all necessary bundles when you work on cxf related projects － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat On 2014-2-12, at 下午6:58, Freeman Fang wrote: Hi, Could you please edit $KARAF_HOME/etc/jre.properties change javax.jws, \ javax.jws.soap, \ to javax.jws;version=2.0, \ javax.jws.soap;version=2.0, \ and cleanly restart karaf? － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat On 2014-2-12, at 下午5:41, Laci Gaspar wrote: Hi I'm having a problem installing a CXF WebService. I'm getting an unresolved constraint error: starting bundle: file:/C:/Users/kit/apache-karaf-2.3.3/deploy/cxf-code-first-bundle-1.0-SNAPSHOT.jar org.osgi.framework.BundleException: Unresolved constraint in bundle cxf-code-first-bundle [186]: Unable to resolve 186.0: missing requirement [186.0] osgi.wiring.package; ((osgi.wiri ng.package=javax.jws)(version=2.0.0)(!(version=3.0.0))) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)[org.apache.felix.framework-4.0.3.jar:] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1247)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1219)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:508)[6:org.apache.felix.fileinstall:3.2.6] at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)[6:org.apache.felix.fileinstall:3.2.6] I tried several examples on the web, no luck. Thanks for your help Laci
Re: Karaf Jenkins
hmm, this is rather strange then. Might be a bug, could you open an issue for it at the Pax Exam Jira with a working sample for reproduction? regards, Achim 2014-02-12 12:45 GMT+01:00 rocket nicholas.martens...@gmail.com: if you didn't define this dependency in your POM and if you didn't run the needed maven plugin depends-maven-plugin it won't work. depends-maven-plugin and curator-client was in the POM all the time the only thing i added was the .version(2.3.0) i dont know if its a bug or a feature but it did work without .version(2.3.0) in karaf 2.3.2 and native container. -- View this message in context: http://karaf.922171.n3.nabble.com/Karaf-Jenkins-tp4031573p4031636.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/
Re: Running command script on startup
Check the etc/shell.init.script file Almost there, Richard :) . I was wondering if I can execute script on container startup, not on shell startup. Thank you. -- Henryk Konsek http://henryk-konsek.blogspot.com
Re: Running command script on startup
Hi Dan, echo list | bin/karaf works, though might not be what you're looking for. I'm thinking more about etc/shell.init.script, but for container startup (not shell startup). Cheers. --- Henryk Konsek http://henryk-konsek.blogspot.com
Strange behavior of the org.apache.karaf.features.FeaturesService in Apache Karaf 2.3.0
Karaf users,
I'm experiencing strange behavior of the concrete implementation of
the org.apache.karaf.features.FeaturesService interface in Apache
Karaf 2.3.0 (as part of JBoss Fuse 6) – please take a look at my use
case and see if you might be able to shed some light on what I’m
experiencing:
I’ve implemented an “agent” that provisions its host Karaf container
using Features (as opposed to bundles or KARs). The agent itself is
also installed/upgraded via the Features mechanism. I’ve recently run
into a strange issue when the agent updates itself; specifically,
after successfully self-updating to a new version (old installs new,
new uninstalls old) and restarting the container the FeaturesService
doesn’t return Features that have BundleInfo objects associated with
them. It’s worth noting that the problem only materializes after a
restart; never before.
As a result, the agent is no longer able to correctly identify its
encapsulating Feature. I use the following code-fragment to identify
the Feature(s) which encapsulate the agent application’s bundle:
public SetFeature getEncapsulatingFeatureSet() {
SetFeature encapsulatingFeatureSet = new HashSetFeature();
String selfBundleLocation = bundleContext.getBundle().getLocation();
Feature[] installedFeatureArray = featuresService.listInstalledFeatures();
for(Feature installedFeature : installedFeatureArray){
for(BundleInfo bundleInfo : installedFeature.getBundles()){
if(selfBundleLocation.equals(bundleInfo.getLocation())){
encapsulatingFeatureSet.add(installedFeature);
logger.info(Encapsulating Feature detected -- +
installedFeature.getName() + / + installedFeature.getVersion());
break;
}
}
}
return Collections.unmodifiableSet(encapsulatingFeatureSet);
}
This has always worked very well and I haven’t had any prior issues.
However, after restarting post-update the List of installed Features
returned by FeaturesService.listInstalledFeatures() do not show up as
having any BundleInfo objects associated with them (for both OOTB and
custom Features) as retrieved by Feature.getBundles().
I admit I’m at a loss to explain why I’m receiving what can only be
described as invalid data (I know these Features should have
BundleInfo objects associated with them). I’m hoping someone might be
able to shed some light on why the FeaturesService is seemingly
behaving strangely (if its operator-error please let me know), and
then only after a restart.
Thank you for your time,
-Steve
Re: Strange behavior of the org.apache.karaf.features.FeaturesService in Apache Karaf 2.3.0
Karaf users,
I realized the scenario I described in my original message might be a
bit complex, possibly obfuscating the issue a bit. This one takes the
“agent” updating itself out of the picture and presents a simpler
scenario that demonstrates the issue. You can think of the agent as
a Feature-installed bundle that leverages the container-provided
FeaturesService service.
1. A Karaf container is run “clean”, and automatically installs
the “agent” Feature via the bootstrap mechanism. The Feature
repository containing the aforementioned “agent” Feature contains two
versions 0.0.1-SNAPSHOT and 0.0.2-SNAPSHOT. The bootstrapping
mechanism takes the newest version and installs it as one would
expect.
2. The container can be started/stopped and the FeaturesService,
as used by the “agent”, works correctly. The BundleInfo objects
associated with each installed Feature are available
(Feature.getBundles()).
3. A new version of the “agent” Feature, 0.0.3-SNAPSHOT, is
added to the Features repository and the “agent” is then instructed to
refresh all repositories (via the same process used by the
“features:refreshurl” shell command – remove/add).
4. The next time the container is restarted the installed
Features returned by the FeaturesService no longer have any BundleInfo
objects associated with them; Feature.getBundles() never returns a
ListBundleInfo that is populated (even when it previously did).
It seems odd that the modification to the Features repository XML
document would cause the FeaturesService (really the Feature objects
it returns) to lose track of the relationship between all Features
(regardless of repo) and their associated bundles. Any clue as to
what might be the cause of this?
Any assistance or advice in this matter is greatly appreciated.
Many Thanks,
-Steve
On Wed, Feb 12, 2014 at 11:01 AM, Steve debianclus...@gmail.com wrote:
Karaf users,
I'm experiencing strange behavior of the concrete implementation of
the org.apache.karaf.features.FeaturesService interface in Apache
Karaf 2.3.0 (as part of JBoss Fuse 6) – please take a look at my use
case and see if you might be able to shed some light on what I’m
experiencing:
I’ve implemented an “agent” that provisions its host Karaf container
using Features (as opposed to bundles or KARs). The agent itself is
also installed/upgraded via the Features mechanism. I’ve recently run
into a strange issue when the agent updates itself; specifically,
after successfully self-updating to a new version (old installs new,
new uninstalls old) and restarting the container the FeaturesService
doesn’t return Features that have BundleInfo objects associated with
them. It’s worth noting that the problem only materializes after a
restart; never before.
As a result, the agent is no longer able to correctly identify its
encapsulating Feature. I use the following code-fragment to identify
the Feature(s) which encapsulate the agent application’s bundle:
public SetFeature getEncapsulatingFeatureSet() {
SetFeature encapsulatingFeatureSet = new HashSetFeature();
String selfBundleLocation = bundleContext.getBundle().getLocation();
Feature[] installedFeatureArray = featuresService.listInstalledFeatures();
for(Feature installedFeature : installedFeatureArray){
for(BundleInfo bundleInfo : installedFeature.getBundles()){
if(selfBundleLocation.equals(bundleInfo.getLocation())){
encapsulatingFeatureSet.add(installedFeature);
logger.info(Encapsulating Feature detected -- +
installedFeature.getName() + / + installedFeature.getVersion());
break;
}
}
}
return Collections.unmodifiableSet(encapsulatingFeatureSet);
}
This has always worked very well and I haven’t had any prior issues.
However, after restarting post-update the List of installed Features
returned by FeaturesService.listInstalledFeatures() do not show up as
having any BundleInfo objects associated with them (for both OOTB and
custom Features) as retrieved by Feature.getBundles().
I admit I’m at a loss to explain why I’m receiving what can only be
described as invalid data (I know these Features should have
BundleInfo objects associated with them). I’m hoping someone might be
able to shed some light on why the FeaturesService is seemingly
behaving strangely (if its operator-error please let me know), and
then only after a restart.
Thank you for your time,
-Steve
Re: Strange behavior of the org.apache.karaf.features.FeaturesService in Apache Karaf 2.3.0
Not sure if that's what you see, but the state of the FeaturesService is
saved in the bundle associated data directory.
So if you install a new bundle and remove the old one, the state would be
lost.
A workaround would be to *update* the bundle instead of install new /
uninstall old.
2014-02-12 21:33 GMT+01:00 Steve debianclus...@gmail.com:
Karaf users,
I realized the scenario I described in my original message might be a
bit complex, possibly obfuscating the issue a bit. This one takes the
agent updating itself out of the picture and presents a simpler
scenario that demonstrates the issue. You can think of the agent as
a Feature-installed bundle that leverages the container-provided
FeaturesService service.
1. A Karaf container is run clean, and automatically installs
the agent Feature via the bootstrap mechanism. The Feature
repository containing the aforementioned agent Feature contains two
versions 0.0.1-SNAPSHOT and 0.0.2-SNAPSHOT. The bootstrapping
mechanism takes the newest version and installs it as one would
expect.
2. The container can be started/stopped and the FeaturesService,
as used by the agent, works correctly. The BundleInfo objects
associated with each installed Feature are available
(Feature.getBundles()).
3. A new version of the agent Feature, 0.0.3-SNAPSHOT, is
added to the Features repository and the agent is then instructed to
refresh all repositories (via the same process used by the
features:refreshurl shell command - remove/add).
4. The next time the container is restarted the installed
Features returned by the FeaturesService no longer have any BundleInfo
objects associated with them; Feature.getBundles() never returns a
ListBundleInfo that is populated (even when it previously did).
It seems odd that the modification to the Features repository XML
document would cause the FeaturesService (really the Feature objects
it returns) to lose track of the relationship between all Features
(regardless of repo) and their associated bundles. Any clue as to
what might be the cause of this?
Any assistance or advice in this matter is greatly appreciated.
Many Thanks,
-Steve
On Wed, Feb 12, 2014 at 11:01 AM, Steve debianclus...@gmail.com wrote:
Karaf users,
I'm experiencing strange behavior of the concrete implementation of
the org.apache.karaf.features.FeaturesService interface in Apache
Karaf 2.3.0 (as part of JBoss Fuse 6) - please take a look at my use
case and see if you might be able to shed some light on what I'm
experiencing:
I've implemented an agent that provisions its host Karaf container
using Features (as opposed to bundles or KARs). The agent itself is
also installed/upgraded via the Features mechanism. I've recently run
into a strange issue when the agent updates itself; specifically,
after successfully self-updating to a new version (old installs new,
new uninstalls old) and restarting the container the FeaturesService
doesn't return Features that have BundleInfo objects associated with
them. It's worth noting that the problem only materializes after a
restart; never before.
As a result, the agent is no longer able to correctly identify its
encapsulating Feature. I use the following code-fragment to identify
the Feature(s) which encapsulate the agent application's bundle:
public SetFeature getEncapsulatingFeatureSet() {
SetFeature encapsulatingFeatureSet = new HashSetFeature();
String selfBundleLocation = bundleContext.getBundle().getLocation();
Feature[] installedFeatureArray =
featuresService.listInstalledFeatures();
for(Feature installedFeature : installedFeatureArray){
for(BundleInfo bundleInfo : installedFeature.getBundles()){
if(selfBundleLocation.equals(bundleInfo.getLocation())){
encapsulatingFeatureSet.add(installedFeature);
logger.info(Encapsulating Feature detected -- +
installedFeature.getName() + / + installedFeature.getVersion());
break;
}
}
}
return Collections.unmodifiableSet(encapsulatingFeatureSet);
}
This has always worked very well and I haven't had any prior issues.
However, after restarting post-update the List of installed Features
returned by FeaturesService.listInstalledFeatures() do not show up as
having any BundleInfo objects associated with them (for both OOTB and
custom Features) as retrieved by Feature.getBundles().
I admit I'm at a loss to explain why I'm receiving what can only be
described as invalid data (I know these Features should have
BundleInfo objects associated with them). I'm hoping someone might be
able to shed some light on why the FeaturesService is seemingly
behaving strangely (if its operator-error please let me know), and
then only after a restart.
Thank you for your time,
-Steve
Frequent Listener timed out, will be ignored exception in log
I am getting following exception in log file quite frequently. Also noticed that sometimes some services are waiting for other services which are shown to be active when i do a list in the console. Are these issues related ? 2014-02-13 11:52:36,895 | WARN | FelixStartLevel | BlueprintEventDispatcher | 4 - org.apache.aries.blueprint.core - 1.3.0 | Listener timed out, will be ignored java.util.concurrent.TimeoutException regards Vinu -- View this message in context: http://karaf.922171.n3.nabble.com/Frequent-Listener-timed-out-will-be-ignored-exception-in-log-tp4031676.html Sent from the Karaf - User mailing list archive at Nabble.com.
