> 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 <osgi-dev@mail.osgi.org> 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 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 _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
