Agree, there are many options on the table. And we have to think through all of them before we start implementing something.
Imo it boils down to 2 different areas: A.) How do ConfigSources know when they need to reload B.) How to 'notify' the 'user code' LieGrue, strub > 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 >> >>>>>> >> >>>>> >> >>>>> >> >>>> >> >>> >> >>> >> > >> >
