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>
>>> 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
>>>
>>>> ----- Original message -----
>>>> From: "Clément Delgrange via osgi-dev" <osgi-dev@mail.osgi.org>
>>>> Sent by: osgi-dev-boun...@mail.osgi.org
>>>> To: OSGi Developer Mail List <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
>>>> 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
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> 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
> Web:
> 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
