You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@deltaspike.apache.org by "l.penet@senat.fr" <l....@senat.fr> on 2015/12/07 12:19:22 UTC
Dynamic configuration
Dear all,
I am reviewing standard configuration mechanisms, such as "DeltaSpike
Configuration Mechanism" (
https://deltaspike.apache.org/documentation/configuration.html ) and
"Apache Commons Configuration" (2.0 still in beta) (
https://commons.apache.org/proper/commons-configuration/index.html ).
I noticed that Apache Commons Configuration 2.0 will provide a support
for dynamic configuration (such as evolving property values).
Do you intend to provide a standard mechanism for that in DS ?
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: Dynamic configuration
Posted by Deven Phillips <de...@gmail.com>.
I, for one, would LOVE to see this as an example/tutorial. Ideally, for me,
I would like to be able to create ConfigResolver which would be backed by
calls to something like etcd or Consul so that configurations are updated
in real-time by the status of other services running in our deployed
environment.
Deven
On Mon, Dec 14, 2015 at 9:14 AM, Gerhard Petracek <gp...@apache.org>
wrote:
> hi ludovic,
>
> great to hear that!
> you are very welcome to donate some hints or a full description (which we
> can add to our documentation).
>
> regards,
> gerhard
>
>
>
> 2015-12-14 14:58 GMT+01:00 l.penet@senat.fr <l....@senat.fr>:
>
> > On 08/12/2015 17:09, Gerhard Petracek wrote:
> >
> >> hi ludovic,
> >>
> >> ConfigResolver is dynamic already and with a custom config-source you
> can
> >> implement or integrate custom concepts easily.
> >>
> > Well, that's what I did.
> > All in all, it is probably the simplest way to go.
> >
> > Thanks,
> >
> >
> > Ludovic
> >
> > |
> > | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
> > |
> >
> >
>
Re: Dynamic configuration
Posted by "l.penet@senat.fr" <l....@senat.fr>.
On 16/12/2015 15:40, Gerhard Petracek wrote:
> hi ludovic,
>
> you don't need to catch an exception, if you are using "true" as 2nd
> argument to do an optional lookup.
> (with using an observer for a startup-event, you don't even need to do an
> optional lookup.)
Thanks for the hint, I will use it asap.
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: Dynamic configuration
Posted by Gerhard Petracek <ge...@gmail.com>.
hi ludovic,
you don't need to catch an exception, if you are using "true" as 2nd
argument to do an optional lookup.
(with using an observer for a startup-event, you don't even need to do an
optional lookup.)
regards,
gerhard
2015-12-16 15:11 GMT+01:00 l.penet@senat.fr <l....@senat.fr>:
> On 16/12/2015 12:45, Gerhard Petracek wrote:
>
>> hi ludovic,
>>
>> what you can do right now is to check BeanManagerProvider#isActive + use
>> an
>> optional lookup via BeanProvider#getContextualReference (or use
>> BeanProvider#injectFields lazily) in your config-source.
>>
> That is exactly what I do ! :-)
>
> But, as I am sure you understood, I would prefer to not even try to get
> configuration values from those sources before CDI is booted.
>
> In fact, I am using something like
>
> if(BeanManagerProvider.isActive()) {
> try {
> myBean = BeanProvider.getContextualReference(MyBean.class);
> } catch(IllegalStateException ise) {
> // happens sometimes when CDI is not fully booted
> myBean = null;
> }
> }
>
> As you can see, I have to catch an exception, because
> BeanManagerProvider#isActive is not enough.
>
>
> Ludovic
>
> |
> | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
> |
>
>
Re: Dynamic configuration
Posted by "l.penet@senat.fr" <l....@senat.fr>.
On 16/12/2015 12:45, Gerhard Petracek wrote:
> hi ludovic,
>
> what you can do right now is to check BeanManagerProvider#isActive + use an
> optional lookup via BeanProvider#getContextualReference (or use
> BeanProvider#injectFields lazily) in your config-source.
That is exactly what I do ! :-)
But, as I am sure you understood, I would prefer to not even try to get
configuration values from those sources before CDI is booted.
In fact, I am using something like
if(BeanManagerProvider.isActive()) {
try {
myBean = BeanProvider.getContextualReference(MyBean.class);
} catch(IllegalStateException ise) {
// happens sometimes when CDI is not fully booted
myBean = null;
}
}
As you can see, I have to catch an exception, because
BeanManagerProvider#isActive is not enough.
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: Dynamic configuration
Posted by Gerhard Petracek <ge...@gmail.com>.
hi ludovic,
what you can do right now is to check BeanManagerProvider#isActive + use an
optional lookup via BeanProvider#getContextualReference (or use
BeanProvider#injectFields lazily) in your config-source.
you could also create a startup-event and use
ConfigResolver#addConfigSources to add a list of managed instances
dynamically.
regards,
gerhard
2015-12-15 13:42 GMT+01:00 l.penet@senat.fr <l....@senat.fr>:
> On 14/12/2015 15:14, Gerhard Petracek wrote:
>
>> hi ludovic,
>>
>> great to hear that!
>> you are very welcome to donate some hints or a full description (which we
>> can add to our documentation).
>>
> Well, what I did is pretty much proprietary.
> I periodically check a modification date, then trigger reconfiguration if
> needed.
>
> If I may suggest one enhancement, anyway... I have, in my case, two kinds
> of configuration :
> * Global, low level configuration, through config files, for things such
> as how to connect to the database.
> * Higher level, sometimes user managed, configuration, stored in DB.
>
> It would have been handy to be able to make a distinction between those
> low level config sources, which require pretty much nothing and those high
> level config sources, which, in my case, require CDI to be booted so that
> entity manger can be instantiated, injected and so on.
>
> Thank you,
>
>
> Ludovic
>
> |
> | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
> |
>
>
Re: Dynamic configuration
Posted by "l.penet@senat.fr" <l....@senat.fr>.
On 14/12/2015 15:14, Gerhard Petracek wrote:
> hi ludovic,
>
> great to hear that!
> you are very welcome to donate some hints or a full description (which we
> can add to our documentation).
Well, what I did is pretty much proprietary.
I periodically check a modification date, then trigger reconfiguration
if needed.
If I may suggest one enhancement, anyway... I have, in my case, two
kinds of configuration :
* Global, low level configuration, through config files, for things such
as how to connect to the database.
* Higher level, sometimes user managed, configuration, stored in DB.
It would have been handy to be able to make a distinction between those
low level config sources, which require pretty much nothing and those
high level config sources, which, in my case, require CDI to be booted
so that entity manger can be instantiated, injected and so on.
Thank you,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: Dynamic configuration
Posted by Gerhard Petracek <gp...@apache.org>.
hi ludovic,
great to hear that!
you are very welcome to donate some hints or a full description (which we
can add to our documentation).
regards,
gerhard
2015-12-14 14:58 GMT+01:00 l.penet@senat.fr <l....@senat.fr>:
> On 08/12/2015 17:09, Gerhard Petracek wrote:
>
>> hi ludovic,
>>
>> ConfigResolver is dynamic already and with a custom config-source you can
>> implement or integrate custom concepts easily.
>>
> Well, that's what I did.
> All in all, it is probably the simplest way to go.
>
> Thanks,
>
>
> Ludovic
>
> |
> | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
> |
>
>
Re: Dynamic configuration
Posted by "l.penet@senat.fr" <l....@senat.fr>.
On 08/12/2015 17:09, Gerhard Petracek wrote:
> hi ludovic,
>
> ConfigResolver is dynamic already and with a custom config-source you can
> implement or integrate custom concepts easily.
Well, that's what I did.
All in all, it is probably the simplest way to go.
Thanks,
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
Re: Dynamic configuration
Posted by Gerhard Petracek <ge...@gmail.com>.
hi ludovic,
ConfigResolver is dynamic already and with a custom config-source you can
implement or integrate custom concepts easily.
however, if you see any concrete limitation, you are very welcome to
provide further details.
regards,
gerhard
2015-12-07 12:19 GMT+01:00 l.penet@senat.fr <l....@senat.fr>:
> Dear all,
>
> I am reviewing standard configuration mechanisms, such as "DeltaSpike
> Configuration Mechanism" (
> https://deltaspike.apache.org/documentation/configuration.html ) and
> "Apache Commons Configuration" (2.0 still in beta) (
> https://commons.apache.org/proper/commons-configuration/index.html ).
>
> I noticed that Apache Commons Configuration 2.0 will provide a support for
> dynamic configuration (such as evolving property values).
> Do you intend to provide a standard mechanism for that in DS ?
>
> Ludovic
>
>
> |
> | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
> |
>
>