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
