They will be public API, currently, mainly used by the ClusterManagementServivice to configure the cluster.
On Wed, Jul 10, 2019 at 9:06 PM Jacob Barrett <jbarr...@pivotal.io> wrote: > Are these new objects public API or internal? > > > On Jul 10, 2019, at 1:16 PM, Jinmei Liao <jil...@pivotal.io> wrote: > > > > We've been working on a new and improved ClusterManagmentService for a > > while now. It allows developers/administrators to manage the clusters > > through rest calls instead of having to use gfsh (more info here: > > > https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service > > ). > > > > Up until now, we've been using the auto-generated POJOs from cache.xsd as > > configuration objects because they contain all cache.xml has to offer. We > > do this with the hope that whatever you can configure using cache.xml, > you > > can configure using this new model. But we also ran into these problems: > > 1. auto-generated code is messy, we had to make way too many adjustments > to > > the generated code in order to improve usage. > > 2. when xsd change, we would have a hard time to re-incorporate the > change > > we made to these objects to the newly generated code. > > 3. these domain objects have deprecated constructs that we do not want to > > expose as public api. > > 4. configuration objects needs to be more intuitive/simple for users to > > configure. > > > > So we are proposing to introduce a new set of configuration objects that > > are dedicated to CMS, and keep the auto-generated xml domain objects as > > internal. And yes, it won't have as much attributes as those xml domain > > objects in the beginning, but we are hoping they will catch up soon. > > > > Concerns/comments? > > -- > > Cheers > > > > Jinmei > -- Cheers Jinmei
