Yea, this is an obvious benefit.

I'm just having troubles to imagine how this should get implemented the best. 
And where do we put the responsibility to detect such a change. In each 
ConfigSource? In the Configuration itself?

To start easy: Consider a ConfigSource for myapp.property. How do you detect a 
change in there? 


LieGrue,
strub





On Sunday, 28 December 2014, 11:44, Romain Manni-Bucau <[email protected]> 
wrote:
>
>Hi
>Most elegant solution ks to change a complete config diff and not a diff by 
>key to allow to rebuikd config if needed. Listener can then listener by key 
>pattern the event - a bit like WithAnnotations.
>Letting client requery the config is not permant enough + will lead to N 
>scheduled threads instead of 1 + forces all clients to have their own refresh 
>listening logic.
>Le 28 déc. 2014 11:00, "Mark Struberg" <[email protected]> a écrit :
>
>Hi!
>>
>>Another feature discussion is around supporting changing configured values 
>>while the application is running.
>>This is the push/pull discussion if you remember.
>>
>>Pull:
>>
>>In DeltaSpike this was not a first class citizen so to say. It was doable 
>>because ConfigResolver always evaluates all the ConfigSources and does not 
>>cache any resolved values. Thus we defer the caching to each ConfigResolver.
>>Of course this only works if you always call 
>>ConfigResolver#getPropertyValue("mykey") and not for injected config values 
>>or if you only resolve the configuration once at startup.
>>
>>Pro:
>> + straight forward
>> + easy to provide
>> + client can define the refresh rate
>>Con:
>> - more code at client
>>
>> - somewhat slower if config values get re-evaluated each time
>> - application needs to handle caching
>>
>>
>>Push:
>>Whenever a configured value gets changed we send an 'event' which can be 
>>observed by the clients. This could be done e.g. in a Swing style with 
>>registering ConfigListeners. Later in a CDI module we could also register a 
>>central ConfigListener which relays this to a CDI Event.
>>
>>
>>Open Questions from my side: who does trigger this event? And when? Do the 
>>ConfigSources detect any change themselves? Or does the admin need to trigger 
>>a 'reload' via JMX or similar?
>>
>>
>>LieGrue,
>>strub
>>
>
>

Reply via email to