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