I have seen a similar thing at a customer. They also used a db as config
backend.
Typically the config is then represented inside the service as either
service.getProperty(key) or service.getConfig as a java bean class.
The problem is that such a solution typically does not provide a way to
push the config to the blueprint beans. You have to actively get it from
the service.
One way to solve this is to create a custom blueprint namespace and
create your own property placeholder support there. This is pretty
advanced stuff though, so I would not recommend it for every case.
What I found is that there are typically two kinds of configs you want
to share:
1. Database properties
2. Service endpoint URLs so you know what URL to use in a client per
Environment
These can also be solved differently though.
1. Use pax-jdbc-config to configure the DataSource in one config. Then
share the DataSource service between bundles instead of the config
2. You can create client proxies that offer an OSGi service to the
inside and do the e.g. Rest call in one central place per service. So
there is again just one place to configure. Alternatively OSGi Remote
Services can provide this in a general way
There are also some similar things like e.g. mail server configs if you
need to send mails. Again the solution is to create a central mail
service that abstracts from the details and is configured in one place.
Such services do not only solve the config problem but also make your
modules more loosely coupled to the technologies used.
Christian
On 25.09.2015 12:45, Kevin Carr wrote:
Christian we use a shared config for each "environment". So bundles
know certain entries will be available in dev qa and prod.
We also have a gui over the db to make it easier for us to update said
properties.
On Fri, Sep 25, 2015, 5:43 AM Christian Schneider
<[email protected] <mailto:[email protected]>> wrote:
You should also look into your architecture to see why you need to
share some config. In some cases you
can extract the commonalities into a service that can then be
regularly configured by config admin.
Can you explain a bit what kind of configuration you need to share
between bundles?
Christian
On 25.09.2015 12:33, Arnaud Deprez wrote:
Hi,
@JP: The problem is not using 2 property placeholder, but sharing
one property placeholder across multiple bundles. And in that
case, it seems that we have to avoid it because it can cause
trouble to the Config Admin due to concurrency issues (it's
actually what I read, I didn't take a look to the code).
@Christian: Thanks for your answer. I actually had the same idea
but I'm a guy who is looking for icing by using Config Admin with
its dynamical behavior :-). But if there is no other solution,
I'll go to that direction.
On Fri, Sep 25, 2015 at 11:34 AM Christian Schneider
<[email protected] <mailto:[email protected]>> wrote:
You can use the <ext:property-placeholder
placeholder-prefix="$[" placeholder-suffix="]"/>
It allows access to the System.properties and use it for
shared config.
See:
https://github.com/apache/karaf/blob/karaf-3.0.x/bundle/core/src/main/resources/OSGI-INF/blueprint/blueprint.xml
It can be used together with a cm:property-placeholder that
contains bundle specific config from config admin.
One problem is that the System properties do not support
updates in case of changes. So you can only use it for
relatively fixed configs.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
