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 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.
LieGrue, strub > Am 05.06.2018 um 09:34 schrieb Romain Manni-Bucau <[email protected]>: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected] >>> : >>>> >>>> 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 <[email protected]> >> 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 >>> >>> >>
