DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
THIS PAGE IS A WORK IN PROGRESS.
...
Overview
This page discusses generation and application of custom configuration elements, as well as their interaction with the ClusterConfigurationService interface.
Please note that, at time of writing, the ClusterConfigurationService is considered @Experimental. Method signatures are subject to change prior to full support.
Background
Historically, cluster member configuration would be saved in a cache.xml, which would be provided to each member at startup. This would require a cluster administrator to maintain individual XML files for each member.
Since Geode 1.0, we have provided as an alternative the cluster-configuration option. In essence, using cluster configuration allowed a cluster's locator(s) would create, store and distribute the necessary XML files to members that require them when the member attempts to join the cluster.
We wish to remove our current reliance on the XML format, and to make available to extension developers a programatic API to interact with the cluster configuration. This is discussed in more detail in the API proposal, linked below.
That public API will require an extension developer to indicate those classes that contain configuration information for their extension objects by having those classes implement CacheElement. Please note that these configuration classes are themselves distinct from the instantiated object whose configuration they represent.
Currently, we use the Java architecture for XML Binding (JAXB) to marshal and unmarshal these configuration objects to and from the XML maintained by the configuration service. As a result, configuration objects must contain the require JAXB annotations. If an extension developer's configuration is defined by an XSD, these files can be easily generated via xjc. An example generation script is provided below.
In a future iteration, the cluster configuration could sore configuration information not as XML, but as the raw configuration object itself. From that point onward, the configuration object's fields will not require the JAXB annotations, as marshaling and unmarshaling to XML will no longer occur.
Additional API proposal and discussion will occur as that date draws closer. In the interim, an extension developer's configuration classes will require the JAXB annotations so that it may interact properly with the existing services.
Note that all of the above discusses only those classes containing configuration information. To reiterate, these configuration classes are themselves distinct from any instantiated extension object or service. Until the internal reliance on XML has been overcome, it will remain that any extension class must implement Extension.
TODO: Extension is still an internal API. Am I advocating the right approach here?
- Episode files have not yet been committed to develop etc/
- Do we expect extension developers to have the Geode source? Can I be referencing
etc/*, or do we need to provide access to those files elsewhere? - Do we care that we find elements in linear-time? If we're requiring that each element is
Identifiable<String>, would a Map be better? I don't have the context for how many elements we expect to be in a single configuration XML. - LuceneCommands is not yet updated to the new style, but if all their methods will stay in a single file, I think it's a good reference for an extending developer.
- Refer to JDBC classes for examples rather than Lucene, since JDBC is already done and Lucene is lower priority.
- Do we want only "top level" config objects to implement CacheElement, or should inner-classes also? It essentially boils down to what needs to be
Identifiable. Whatever our choice, some of our own Impl is inconsistent.
Overview
This page discusses generation and application of custom configuration elements, as well as their interaction with the ClusterConfigurationService interface.
Please note that, at time of writing, the ClusterConfigurationService is considered @Experimental. Method signatures are subject to change prior to full support.
Placement of Configuration Elements within the Configuration
...
- Example generation files. Unpack these in your Apache Geode root directory.
- Also refer to
- Public API for Retrieving/Updating Cluster Configuration Service Interface