Re: [osgi-dev] Configurator resources that depend on a ConfigurationPlugin

[Carsten Ziegeler via osgi-dev]

Hi Clément,

with a configurator plugin you run into the same problem as with 
configuration plugins - the configurator plugin needs to be there in 
order to work. So in addition to a plugin mechanism you would need a 
mechanism to ensure the availability of the plugin. And this means you 
can run into the same situations - just on a different level - as you 
can run today with configuration plugins.


It's true that with Jürgen's possibility 2 you can't use an OSGi 
configuration for your plugin; you could use a different way of 
configuring that.


Funnily, when we designed the configurator specification I was arguing 
for some time to get a such a plugin mechanism for the configurator.
And I was *convinced* that the configuration plugin should be enough 
(with the additions we did around that area). Please keep in mind that 
this is version 1.0 of the configurator specification. Nothing prevents 
us from extending it.


Regards
Carsten

Am 10.10.2019 um 17:36 schrieb Clément Delgrange:

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)


But a ConfigurationPlugin cannot delay a configuration (to not deliver the 
configuration to the target until a condition is met)?

  * With the Tim's solution, configuration targets can receive wrong 
configurations at startup that may trigger wrong behaviors or at least a lot of 
exceptions in my activate methods. I suppose that with DS and Metatype the 
system will be more stable, isn't it? It is maybe the best solution in my case.
  * With Jürgen's possibility 1, service implementations must know how they 
will be configured. Impossible in my case.
  * With Jürgen's possibility 2, if my configuration plugin needs a 
configuration (eg; user/password for a database) it will be never activated!?

A configurator plugin would have been easier to implement and would have 
improved startup stability, no?

In any case, thank you for your precious help!

Clément.






‐‐‐ Original Message ‐‐‐
On Thursday 10 October 2019 12:12, Carsten Ziegeler via osgi-dev 
 wrote:


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 

Re: [osgi-dev] Configurator resources that depend on a ConfigurationPlugin

[Clément Delgrange via osgi-dev]

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

But a ConfigurationPlugin cannot delay a configuration (to not deliver the 
configuration to the target until a condition is met)?

 * With the Tim's solution, configuration targets can receive wrong 
configurations at startup that may trigger wrong behaviors or at least a lot of 
exceptions in my activate methods. I suppose that with DS and Metatype the 
system will be more stable, isn't it? It is maybe the best solution in my case.
 * With Jürgen's possibility 1, service implementations must know how they will 
be configured. Impossible in my case.
 * With Jürgen's possibility 2, if my configuration plugin needs a 
configuration (eg; user/password for a database) it will be never activated!?

A configurator plugin would have been easier to implement and would have 
improved startup stability, no?

In any case, thank you for your precious help!

Clément.






‐‐‐ Original Message ‐‐‐
On Thursday 10 October 2019 12:12, Carsten Ziegeler via osgi-dev 
 wrote:

> 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 

Re: [osgi-dev] Configurator resources that depend on a ConfigurationPlugin

[Carsten Ziegeler via osgi-dev]

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


- Original message -
From: "Clément Delgrange via osgi-dev" mailto:osgi-dev@mail.osgi.org>>
Sent by: osgi-dev-boun...@mail.osgi.org

To: OSGi Developer Mail List 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 

Re: [osgi-dev] Configurator resources that depend on a ConfigurationPlugin

[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 
 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  
>>> 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" 
 Sent by: osgi-dev-boun...@mail.osgi.org
 To: OSGi Developer Mail List 
 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
>>
>> 

Re: [osgi-dev] Configurator resources that depend on a ConfigurationPlugin

[Jürgen Albert via osgi-dev]

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

- Original message -
From: "Clément Delgrange via osgi-dev" mailto:osgi-dev@mail.osgi.org>>
Sent by: osgi-dev-boun...@mail.osgi.org

To: OSGi Developer Mail List 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 
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

Re: [osgi-dev] Configurator resources that depend on a ConfigurationPlugin

[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  
> 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" 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List 
> 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

Re: [osgi-dev] Configurator resources that depend on a ConfigurationPlugin

[BJ Hargrave via osgi-dev]

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 HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: "Clément Delgrange via osgi-dev" Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List Cc:Subject: [EXTERNAL] [osgi-dev] Configurator resources that depend on a ConfigurationPluginDate: 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 Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev 
 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev