issue if you need to trigger manually a refresh method is you often miss bulk updates and then have this sequence:
updateSource1(); refreshConfig(); updateSource2(); refreshConfig(); updateSource3(); refreshConfig(); When you wanted updateSource1(); updateSource2(); updateSource3(); refreshConfig(); I'm not sure skipping this thread is really possible. We can allow to provide the "scheduler" (actually not sure we have the choice) so one impl can be synchronous where the default would be a scheduled task. In this last case the refresh() call would just be a flag set to true in the scheduled task or sthg like that. In all cases having a batch view of the diff is mandatory to be able to update correctly during runtime the configurations. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-28 16:13 GMT+01:00 Anatole Tresch <[email protected]>: > Hi Mark > > the point with the values is indeed important. Keys basically IMO are > enough, so a client knows if it is affected from the change or not ;) > Basically tree vs list maps to the same discussion as with priorities vs > more complex structures. Basically you can see it as implementation detail > of a PropertySource as well. But I agree a simple list is definitively > easier to handle internally... > > > Mark Struberg <[email protected]> schrieb am Sun Dec 28 2014 at 16:00:53: > >> @Oliver: >> >> >> > For a file based resource it is eays. We > take the last modified date. >> >> >> But WHEN does the ConfigSource detect this? It would be easy for the >> 'pull' approach, but not that easy for 'push'. The ConfigSource simply >> doesn't get asked again. That boils down to scheduling again imo. >> >> >> > the event will contain the set of changed properties. >> This might become a security risk later, so I'd rather not send them. >> Probably just send the keys, but surely not the values. Can you live with >> that? >> >> Consider someone changes mydatabase.user.password=somenewpassword and all >> the world is seeing it ;) >> >> >> >> @Anatole: >> ad A1: we need to try out how such an interface would look like >> ad A1I: agree >> ad A1II: I'd _not_ make the ConfigSources a Tree but really just a sorted >> List. What benefit would a Tree structure add? >> >> ad B: fine for me. Same concern regarding security as with Olivers >> approach though. >> >> >> >> LieGrue, >> strub >> >> >> On Sunday, 28 December 2014, 15:10, Anatole Tresch <[email protected]> >> wrote: >> > >> > >> >A) >> > A1) If a ConfigSource supports some kind of programmatic mutability, >> when the changes are committed. >> > A2) If its underlying sources (I) or config sources (II) are changed: >> > I is an implementation detail of the ConfgSource >> > II by listening on changes of its child ConfigSources >> >B) >> > I would propose an observer patterns, managing observers using Weak >> refs. >> > Payload something like a ConfigChangeSet, containing >> > - a reference to the config source (or the config source name -> >> namespaces !) >> > - a set of changes, e.g. PropertyChangeEvents, where propertyName = >> property key >> > >> > >> >WDYT...? >> > >> > >> > >> >Mark Struberg <[email protected]> schrieb am Sun Dec 28 2014 at 14:54:36: >> > >> >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 >> >>>> >>>>>> >> >>>> >>>>> >> >>>> >>>>> >> >>>> >>>> >> >>>> >>> >> >>>> >>> >> >>>> > >> >>>> >> >>> >> >> >> > >> > >>
