On Sunday, 28 December 2014, 13:59, John D. Ament <[email protected]>
wrote:
I think trying to add threads and polling would be a bad idea for now (too
heavy for a first pass). I think an initial pass can be as simple as
provide an API that reloads any configuration data under a specific
source. Allow the app developer to control when they want to see
configuration data. It could be through an admin interface (in a webapp)
or an RMI/JMX method or a JMS message coming in..
If we did have a timer/thread, I think instead of an event we use a
functional interface to represent the call back to make when new config is
ready, perhaps taking the ChangeSet as an argument. Perhaps the CDI
integration can have a default implementation of this that fires an event.
There is going to be config data we want to reload at runtime though (max #
of user sessions) vs config data we don't want to reload quite yet (change
the HTTP listen port; oops just brought down the environment..)
On Sun Dec 28 2014 at 7:44:15 AM Mark Struberg <[email protected]> wrote:
The Environment is a different story I think. As far as I've seen it is
more like a mixture of DeltaSpikes ProjectStage and other
'features' like
dbvendor, tenant, etc.
That will be another huge brainstorming...
LieGrue,
strub
> On Sunday, 28 December 2014, 12:43, Romain Manni-Bucau <
[email protected]> wrote:
> > should be configurable for sure but we'll get this internal
config
> issue anyway (Environment of Anatole i guess). I'd just start with
> system props and acceptable defaults.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
>
> 2014-12-28 12:40 GMT+01:00 Mark Struberg <[email protected]>:
>> That could work. But what schedule time do you use, etc.
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> On Sunday, 28 December 2014, 12:21, Romain Manni-Bucau
> <[email protected]> wrote:
>>
>>
>>>
>>>
>>> I d start with a scheduled thread rebuilding a transient
config. Then
it
> does a diff against current one. If the diff is not empty it switches
the
> current config and sends the event.
>>> Le 28 déc. 2014 12:01, "Mark Struberg"
> <[email protected]> a écrit :
>>>
>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
