Right, using ConfigAdmin is the way to go in OSGi. If you use
blueprint for example, you just have to define a specific proprty
placeholder and it's really easy to use.
On Thursday, December 9, 2010, Freeman Fang freeman.f...@gmail.com wrote:
Hi,
You can put properties in $KARAF_HOME/etc
I'm trying to make my Karaf service more resilient to shutdown. In
particular I want my Camel routes to shutdown gracefully. I started this
discussion a few months ago, see
http://www.mail-archive.com/user@karaf.apache.org/msg00084.html.
Guillaume created the JIRA ticket KARAF-176 which is also
It depends on the configuration admin. Karaf uses etc directory for these
configurations - eg. If you persistence id is set to com.mycompany any
changes in $KARAF_BASE/etc/com.mycompany.cfg will be visible for your
components. It doesn't look classpath, it looks into etc directory. That's
better
Ok.
If I have 4 bundles that all use JMS, and they are named:
myApp.bundle1
myApp.bundle2
myApp.bundle3
myApp.bundle4
Would I need 4 configuration files in etc:
myApp.bundle1.cfg
myApp.bundle2.cfg
myApp.bundle3.cfg
myApp.bundle4.cfg
?
- Original Message -
No,
These bundles may reffer same persistent id (configuration file) without
problems.
In fact - you may introduce new bundle which produces connection factory and
export it as service to reduce number of configuration dependencies.
Best regards,
Lukasz
-Original Message-
From: Mike
We were just talking about the differences between bundles we should use as
services, and bundles that simply need to be wired. In my definition, all
cross-cutting concerns should be services consumed by their bundles. We also
have been discussing whether or not the services should all be
If you use ConfigAdmin directly or indirectly, you need to specify a
configuration id to load the properties from. A single configuration
can be used by multiple bundles at the same time, so it's just about
using the same id for multiple bundles.
If you name the file myApp.cfg, the id of the
Please create a new JIRA issue and link to the old one.
Also, it would be nice to try with the latest trunk in case this has
been fixed already, but I fear that JavaServiceWrapper may just kill
the JVM abrubtly in some cases. Does the problem only happen on
windows or is that also happening on
