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
<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
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
