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 > > > > >
