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 >>>> >>> >>> >> > >
