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