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