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