Le mar. 5 juin 2018 à 10:25, Mark Struberg <strub...@yahoo.de.invalid> a écrit :
> Interesting solution, but I fear there are 2 problems with this: > a.) It won't be backward compatible with existing ConfigSources out in the > wild > Well we don't support it and the lasttimestamp solution has the same issue so kind of status quo ;) > b.) It's likely an overkill. That solution would make sense if you have a > tons of changes, but not if there is barely something which moves. > Not really. it is more about: is the source pushing its changes or the config polling them. I think the push solution is saner and in this case doesn't require the polling and lasttimestamp at all, no? > > LieGrue, > strub > > > Am 05.06.2018 um 09:34 schrieb Romain Manni-Bucau <rmannibu...@gmail.com > >: > > > > Hmm, maybe too early so don't hesitate to shout if studid: why not > having a > > config manager sources can register in it and if this manager has >= 1 > > source then the thread is active otherwise it is destroyed > > (running.set(false)) > > The source would be able to pass its refresh logic (as a function more or > > less) the thread will execute in a safe manner (if fail - log but dont > quit > > the loop) and it returns a boolean to ask to propagate changes upstream > or > > not. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le mar. 5 juin 2018 à 09:23, Jean-Louis MONTEIRO <jeano...@gmail.com> a > > écrit : > > > >>>> Some values may have been updated, some might have been deleted and > some > >>>> other added. > >>>> Returning a set might not be enough, isn't it? > >> > >>> We really only need the property names which got changed: > >>> * new ones > >>> * deleted ones > >>> * the ones with different values > >>> > >>> So a Set<String> is fine. > >> > >> The thing is that you will get the key of everything that changed which > >> requires to invalidate the cache for all entries (lock?). > >> Or you would need to iterate all the keys, compare again old/new and > delete > >> entries from cache, do nothing for add (? they will be lazily added > during > >> lookup maybe) and invalidate the updated values. > >> > >> That seems to be heavy to handle for nothing has during compare we have > all > >> information already. > >> > >> > >> > >> Le mar. 5 juin 2018 à 09:10, Mark Struberg <strub...@yahoo.de.invalid> > a > >> écrit : > >> > >>> Hi JL! > >>> > >>> Thanks for the feedback! > >>> And yes, this will also be important for ConfigJSR (and later mp-config > >> as > >>> well). > >>> > >>> > >>>> First it's all about config, so maybe having a method name "diff" is > >>>> enough. No need for "diffConfig". > >>> > >>> Well, diff alone is imo a bit too short as it doesn't have any context > >>> about what to diff. > >>> Thus I'd prefer diffConfig. > >>> > >>> > >>>> Some values may have been updated, some might have been deleted and > >> some > >>>> other added. > >>>> Returning a set might not be enough, isn't it? > >>> > >>> We really only need the property names which got changed: > >>> * new ones > >>> * deleted ones > >>> * the ones with different values > >>> > >>> So a Set<String> is fine. > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>>> Am 05.06.2018 um 08:59 schrieb Jean-Louis MONTEIRO < > jeano...@gmail.com > >>> : > >>>> > >>>> Few thoughts ... > >>>> > >>>> I did not follow really deltaspike to be honest, but I do follow > >>> MP-Config > >>>> for instance. > >>>> > >>>> First it's all about config, so maybe having a method name "diff" is > >>>> enough. No need for "diffConfig". > >>>> > >>>> Some values may have been updated, some might have been deleted and > >> some > >>>> other added. > >>>> Returning a set might not be enough, isn't it? > >>>> > >>>> Jean-Louis > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Le mar. 5 juin 2018 à 08:55, Mark Struberg <strub...@yahoo.de.invalid > > > >> a > >>>> écrit : > >>>> > >>>>> Hi folks! > >>>>> > >>>>> For the new DS-1.9 feature to 'push' config changes we need an > >> algorithm > >>>>> to detect whether an old and a new config differs. > >>>>> > >>>>> The signature would be something like: > >>>>> > >>>>> /** > >>>>> * > >>>>> * A Set of all the attributes which differ between the old and new > >>> config > >>>>> Map. An empty Set if there is no difference. > >>>>> */ > >>>>> public Set<String> diffConfig(Map<String, String> oldValues, > >> Map<String, > >>>>> String> newValues) > >>>>> > >>>>> This is intended for e.g. background threads which read from a > >> database > >>>>> once per second and compare the old values with the new ones. > >>>>> If there was any difference then the set of attributes get reported > >> back > >>>>> to the Config (which in turn clears the caches, etc). > >>>>> > >>>>> > >>>>> Now where to put this method? > >>>>> > >>>>> My candidate would be > >>>>> org.apache.deltaspike.core.api.config.ConfigResolver.ConfigProvider > >>>>> I do not want to put it into the Config interface itself because it > is > >>> not > >>>>> a user contract thingy. > >>>>> And I also do not want to put it into ConfigResolver becasue I'd like > >> to > >>>>> have the impl only available internally and not bloat the > >> ConfigResolver > >>>>> any further. > >>>>> > >>>>> Wdyt? > >>>>> > >>>>> LieGrue, > >>>>> strub > >>> > >>> > >> > >
