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 >
