Oh, we DO push from the ConfigSource to Config in the current solution! It's just that we _right now_ do only leverage this for eagerly invalidating our caches.
We could later also introduce active notifications based on the infos we gather. But there are many things we need to clarify before doing so. LieGrue, strub > Am 05.06.2018 um 10:33 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > 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 >>>>> >>>>> >>>> >> >>
