Running command script on startup

[Henryk Konsek]

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

Problem installing cxf WebService

[Laci Gaspar]

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

[Richard Kettelerij]

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  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

[Daniel McGreal]

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  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

[simafengyun1984]

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

[Freeman Fang]

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

[Freeman Fang]

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

[Achim Nierbeck]

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 :

> 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  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Re: Karaf & Jenkins

[rocket]

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

[Achim Nierbeck]

Hi,

see my comments inline.

regards, Achim

2014-02-12 12:27 GMT+01:00 rocket :

> 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  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Re: Karaf & Jenkins

[rocket]

"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

[Laci Gaspar]

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

[Achim Nierbeck]

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 :

> "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  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Re: Running command script on startup

[Henryk Konsek]

> 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

[Henryk Konsek]

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

[Steve]

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 Set getEncapsulatingFeatureSet() {
Set encapsulatingFeatureSet = new HashSet();
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

[Steve]

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
List 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  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 Set getEncapsulatingFeatureSet() {
> Set encapsulatingFeatureSet = new HashSet();
> 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

[Guillaume Nodet]

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 :

> 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
> List 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  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 Set getEncapsulatingFeatureSet() {
> > Set encapsulatingFeatureSet = new HashSet();
> > 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 aft

Frequent "Listener timed out, will be ignored" exception in log

[Vinu Raj]

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.