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
