You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Overview

Currently, the only way for a developer to modify cluster configuration is through internal methods or to manually edit the configuration file while the cluster is offline.
It can be expected that a developer will create commands or functions that require information in or modification of the cluster configuration.
Therefore, we should expose a public API for the cluster configuration, to promote correctness and ease of use.

Background

The cache-1.0.xsd defines the permissible structure of the cluster config, currently represented in XML.
Developers can include their own cluster configuration elements in one of two places as defined in the cache-1.0.xsd: at the cache level or at the region level.
These accept any XML element, so long as the namespace does not match Geode's (i.e., {{http://geode.apache.org/schema/cache}}).

Goals

  • Expose a clean Java API for retrieval and modification of the cluster configuration, as well as injection of elements into the cache and region levels of the cluster configuration.
  • Do not require a developer to explicitly define methods to translate a configuration object to or from XML

Approach

  • Define a no-op interfaces CacheElement and RegionElement to identify classes that may be saved to the cache and region XML entities, respectively.
  • Leverage JAXB to generate an initial set of configuration objects.  
  • Expose ClusterConfigurationService via the cache, provided a locator is managing that cache.

Proposal

As a minimum viable product, we would require only two methods: a getter and an updater.


public interface ClusterConfigurationService {

 /**
 * @param group The group to which the cluster configuration applies.
 * For configuration that applies to every member, use the group "cluster".
 * @param additionalBindClass These classes will allow the returned CacheConfig to include objects
 * if the bound types, rather than defaulting to {@link com.sun.org.apache.xerces.internal.dom.ElementNSImpl}
 * to represent the configuration elements XML.
 * @return The cluster configuration for the specified group.
 */
 CacheConfig getCacheConfig(String group, Class... additionalBindClass);

 /**
 * @param group The group to which the cluster configuration applies.
 * For configuration that applies to every member, use the group "cluster".
 * @param mutator Specification of how the cluster configuration should be altered.
 * @param additionalBindClass These classes will allow the returned CacheConfig to include objects
 * if the bound types, rather than defaulting to {@link com.sun.org.apache.xerces.internal.dom.ElementNSImpl}
 * to represent the configuration elements XML.
 */
 void updateCacheConfig(String group, UnaryOperator<CacheConfig> mutator, Class... additionalBindClass);

}

We accept the UnaryOperator to mutate the existing cluster configuration rather than accepting an explicit CacheConfig to overwrite the existing cluster configuration in the interest of safe concurrent access.  

For additional utility, each method could assume group = "cluster" when not provided.

 

The ClusterConfigurationService will be made available from the Cache, provided the Cache is managed by a Locator.  The service is unavailable for other members.

Long-term Goals

  • Reduce duplication of effort by replacing "creation" classes (i.e., CacheCreation, RegionCreation, BindingCreation, et al)
  • Remove requirement of JAXB / XML annotations on configuration element classes.
  • No labels