Here's a commit w/ an example of what this might look like, from a purely programmatic approach.
https://github.com/johnament/tamaya/commit/a1777439892646023e62f8ce08c4bcaf109b4aca On Sun Dec 28 2014 at 9:12:58 AM Oliver B. Fischer <[email protected]> wrote: > +1 for changing configurations. For example we use feature toogles a lot > and one common problem is to activate them or to turn them off. This > would be easier with a configuration framework which allows to change > values easily. > > The change should be only propagated if the new configuration differs > from the old one. Let me give you an example: > > - App starts and reads configuration > - config source is a file and is updated by an external service > - Tamaye detects update of the file an reads it > - if the updated file does not contains any value change no event will > be send > > So the mechanism *must be able* to handle this. > > Oliver > > Am 28.12.14 um 10:59 schrieb Mark Struberg: > > 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 > > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E [email protected] > S oliver.b.fischer > J [email protected] > X http://xing.to/obf > >
