We explicitely decided against an additional plugin mechanism for the
configurator as that one is not really needed. It's not important what
configuration admin stores (the place holders or the final values), its
important what configuration admin delivers. And for that use case a
configuration plugin works.
For your use case you can implement two configuration plugins.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
Am 10.10.2019 um 08:37 schrieb Clément Delgrange via osgi-dev:
Thanks for your help,
Jürgen and Tim's solutions could meet my needs, but as BJ said values
are replaced each time the configuration is delivered to the target and
as I understand not saved. Maybe it is appropriate just for password and
secrets. My application configurations generally contain "structural"
properties (eg; myreference.target=), stable properties (eg;
url.to.publickey=), properties that change according to the environment
(cache.policy=) and secret properties. It would be nice if the
configurator could in addition handle placeholders, if it was the case,
I could provide "structural" and stable properties inside an application
bundle, changing properties could be resolved by a ConfiguratorPlugin
(the source can be easier to administrate, no PIDs) and secrets by a
ConfigurationPlugin. Does that make sense?
Clement
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday 8 October 2019 20:41, Jürgen Albert via osgi-dev
<osgi-dev@mail.osgi.org> wrote:
Hi Clement,
we have discussed this problem you have at a OSGi meeting and Carsten
Ziegler implemented something that goes beyond the Spec, that might
help you I assume here that you are using the Felix ConfigAdmin. See:
https://issues.apache.org/jira/browse/FELIX-6059
You have to possibilities:
1. The ConfigAdmin will be registered with a property config.plugins,
that names all ConfigurationPlugins that serve a property
config.plugin.id. Thus register your plugin with e.g.
config.plugin.id=my.id. Add a mandatory Service reference for the
Config Admin with a target filter like (config.plugins=my.id) in the
service that needs configuration. With this your Service will be
activated after the ConfigAdmin knows about you plugin and handles the
properties accordingly.
2. If you start your runtime with a framework property
felix.cm.config.plugins=my.id1,my.id2 the ConfigAdmin will not become
active and registered until the a Plugin with config.plugin.id=my.id1
and config.plugin.id=my.id2 is available.
I hope this helps,
Jürgen.
Am 08/10/2019 um 16:27 schrieb Tim Ward via osgi-dev:
My question is, how can I tell to the Configurator bundle to not
process resources that contains placeholder until my
ConfigurationPlugin is up?
There are ways that you could attempt to do this, however they’re all
inelegant and error prone. What would make more sense would be for
the ConfigurationPlugin to detect the existing configurations which
contain placeholders at startup and trigger an update for them. This
will cause the configuration to be re-delivered, including any
necessary configuration plugin execution.
In general you are better off trying to make things ordering
independent rather than to control the order that things happen in.
The result is a much more flexible and stable system.
Best Regards,
Tim
On 8 Oct 2019, at 12:54, BJ Hargrave via osgi-dev
<osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote:
Configuration Plugins mutate configuration data each time it is
delivered to a configuration target. So the Configuration Plugin
must be active before any configuration targets which care about the
mutated configuration data.
So this is orthogonal to Configurator which is about putting
configuration data in the CM configuration data store.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>
----- Original message -----
From: "Clément Delgrange via osgi-dev" <osgi-dev@mail.osgi.org
<mailto:osgi-dev@mail.osgi.org>>
Sent by: osgi-dev-boun...@mail.osgi.org
<mailto:osgi-dev-boun...@mail.osgi.org>
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org
<mailto:osgi-dev@mail.osgi.org>>
Cc:
Subject: [EXTERNAL] [osgi-dev] Configurator resources that
depend on a ConfigurationPlugin
Date: Tue, Oct 8, 2019 06:08
Hi all,
I have a question regarding the Configurator and the
ConfigurationPlugin spec. I would like to provision my
application with configurations as I do with my the bundles, for
this the Configurator seems perfect. But, the values inside my
configurations could be different depending of the environment
(dev, beta, prod, ...) and my configurations may contain
sensitive data that I don't want in my Git repo. In this case I
think I could provide a ConfigurationPlugin which will replace
placeholders with data coming from a database.
My question is, how can I tell to the Configurator bundle to not
process resources that contains placeholder until my
ConfigurationPlugin is up?
Thanks,
Clément Delgrange.
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Jürgen Albert
Geschäftsführer
Data In Motion Consulting GmbH
Kahlaische Str. 4
07745 Jena
Mobil: 0157-72521634
E-Mail:j.alb...@datainmotion.de <mailto:j.alb...@datainmotion.de>
Web:www.datainmotion.de <http://www.datainmotion.de>
XING:https://www.xing.com/profile/Juergen_Albert5
Rechtliches
Jena HBR 513025
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
