for normal usages, developers will only need to use the updateCacheConfig(groupName, mutator) api, like:
service.updateCacheConfig("cluster", cacheConfig->{ cacheConfig.getRegion().add(aRegionConfig); cacheConfig.getAsyncEventQueue().add(aQueue); return cacheConfig; }); Only when module developers who wants to add a custom cache element (with its own xsd) or region element, will need to use the other set of helper apis, example ConnectorService connector = new ConnectorService("id"); servcie.saveCacheElement("cluster", connector); service.deleteCacheElement("cluster", "id", ConnectorService.class); or service.saveRegionElement("cluster", "regionName", aRegionElement); service.deleteRegionElement("cluster", "regionName", "id", Element.class) On Tue, Mar 13, 2018 at 12:55 PM, Patrick Rhomberg <prhomb...@pivotal.io> wrote: > Hmm... Jinmei has it right -- that the *Element were for declaring custom > XML entries -- but they were only really used during exploration. With > this minimal API, we're not actually using those interface-tags in a > publicly-visible way... > > Now I'm torn. On the one hand, it seems a bit strange to require a > developer to use an interface that doesn't have an obvious use. On the > other hand, I'm hesitant to allow an arbitrary Object to be passed to the > XML to be saved, just as type-safety and to ensure intent. > > Thoughts on "Versatility" vs "Declared Intent"? > > Regarding naming, I could see it either way, too. "cache config" makes > sense since it is modifying the "cache" portion of the configuration XML. > "cluster configuration" makes sense since it is shared across the cluster, > although there are separate configurations for each member group as well. > > On Tue, Mar 13, 2018 at 11:14 AM, Jinmei Liao <jil...@pivotal.io> wrote: > > > 1. CacheElement/RegionElement are used for custom xml element that are to > > be added by other modules. They are not meant for those elements defined > by > > cache.xsd already, like region, gatewayreceiver etc. Maybe we should > rename > > it back CustomCacheElement/CustomRegionElement > > > > 1. the mutator updates the CacheConfig object which holds all the > elements > > inside cache including regions, indexes and the custom elements. the api > is > > updateCacheConfig > > > > On Tue, Mar 13, 2018 at 10:55 AM, Sai Boorlagadda < > > sai.boorlaga...@gmail.com > > > wrote: > > > > > I have few comments: > > > > > > 1, What is ClusterElement/RegionElement interfaces used for? > > > > > > 2. I see that using unary mutator one can mutate both cache and region > > > configurations, so the methods in ClusterConfigurationService can be > > > getClusterConfig and updateClusterConfig? The naming is debatable as > > region > > > configuration is part of CacheConfig, so technically user is updating > > > CacheConfig even for region changes and changing a group's > configuration > > is > > > not cluster configuration. So I think updateCacheConfig is a better > name > > > than updateClusterConfig? > > > > > > On Mon, Mar 12, 2018 at 4:11 PM, Patrick Rhomberg < > prhomb...@pivotal.io> > > > wrote: > > > > > > > Hello all. > > > > > > > > Please refer to the wiki page [1] for a proposal to expose > > modification > > > > of cluster configuration. > > > > In short, this proposes an endpoint for developers to modify or > > extend > > > > cluster configuration functionalities. This would eventually replace > > > > existing configuration classes (e.g., CacheCreation). > > > > The proposed intends to use JAXB to generate and translate between > > Java > > > > Objects and the underlying cache configuration's XML. Examples of > > these > > > > generated classes are included in the proposal's Resources section. > > > > Regards. > > > > > > > > Imagination is Change. > > > > ~Patrick > > > > > > > > [1] > > > > https://cwiki.apache.org/confluence/display/GEODE/ > > > Public+API+for+Cluster+ > > > > Configuration > > > > > > > > > > > > > > > -- > > Cheers > > > > Jinmei > > > -- Cheers Jinmei