Hi Mark the point with the values is indeed important. Keys basically IMO are enough, so a client knows if it is affected from the change or not ;) Basically tree vs list maps to the same discussion as with priorities vs more complex structures. Basically you can see it as implementation detail of a PropertySource as well. But I agree a simple list is definitively easier to handle internally...
Mark Struberg <[email protected]> schrieb am Sun Dec 28 2014 at 16:00:53: > @Oliver: > > > > For a file based resource it is eays. We > take the last modified date. > > > But WHEN does the ConfigSource detect this? It would be easy for the > 'pull' approach, but not that easy for 'push'. The ConfigSource simply > doesn't get asked again. That boils down to scheduling again imo. > > > > the event will contain the set of changed properties. > This might become a security risk later, so I'd rather not send them. > Probably just send the keys, but surely not the values. Can you live with > that? > > Consider someone changes mydatabase.user.password=somenewpassword and all > the world is seeing it ;) > > > > @Anatole: > ad A1: we need to try out how such an interface would look like > ad A1I: agree > ad A1II: I'd _not_ make the ConfigSources a Tree but really just a sorted > List. What benefit would a Tree structure add? > > ad B: fine for me. Same concern regarding security as with Olivers > approach though. > > > > LieGrue, > strub > > > On Sunday, 28 December 2014, 15:10, Anatole Tresch <[email protected]> > wrote: > > > > > >A) > > A1) If a ConfigSource supports some kind of programmatic mutability, > when the changes are committed. > > A2) If its underlying sources (I) or config sources (II) are changed: > > I is an implementation detail of the ConfgSource > > II by listening on changes of its child ConfigSources > >B) > > I would propose an observer patterns, managing observers using Weak > refs. > > Payload something like a ConfigChangeSet, containing > > - a reference to the config source (or the config source name -> > namespaces !) > > - a set of changes, e.g. PropertyChangeEvents, where propertyName = > property key > > > > > >WDYT...? > > > > > > > >Mark Struberg <[email protected]> schrieb am Sun Dec 28 2014 at 14:54:36: > > > >Agree, there are many options on the table. And we have to think through > all of them before we start implementing something. > >> > >> > >>Imo it boils down to 2 different areas: > >>A.) How do ConfigSources know when they need to reload > >>B.) How to 'notify' the 'user code' > >> > >>LieGrue, > >>strub > >> > >> > >> > >> > >>> On Sunday, 28 December 2014, 13:59, John D. Ament < > [email protected]> wrote: > >>> > 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 > >>>> >>>>>> > >>>> >>>>> > >>>> >>>>> > >>>> >>>> > >>>> >>> > >>>> >>> > >>>> > > >>>> > >>> > >> > > > > >
