Hi Mark, Personally I see it as an internal of a source which fakes to be a map but is actually key based (= not able to load all values up to date at once like a database) so i'm tempted to say we should do like for EE projects and create a config-source module with all the utilities for users in a portable way (today a user requires to use impl which is not as clean as we are normally since it mixes extensible classes by users and internals).
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:00, Jean-Louis MONTEIRO <jeano...@gmail.com> a écrit : > 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 >
