...
The moment you want to call the CMS API, you find yourself in need of two basic types for your Element: a Configuration object and a RuntimeInfo.
Configuration ObjectConfigurationConverterConfigurationConverter
This objects specifies how you want to configure this element like Region, Index, GatewayReceiver etc. To get started, consider only adding those attributes that you want to expose through rest api. For example, although according to the cache.xsd, a region can be configured with many attributes (see RegionConfig, which is generated by the jaxb service using the cache.xsd file), in rest management api, we don't want to overwhelm users, so we only expose those that are more commonly used. That would require us to expose a different configuration object called Region (better to put all configuration object in one package).
...
Now that you have the configuration object ready, you will need to create a ConfigurationManager that tells the framework how this object is to be managed by the configuration service. If your configuration object is part of the cache xml, your configuration manager should extend CacheConfigurationManager. If your object affects other parts outside cache.xml, like jar deployment or runtime properties, you will need to extend its parent class ConfiguratioonManager.
CacheConfigurationManager
Configuration Validator
...
For now, after you created a configuration manager, you will need to manually add it to the map in the list of managers in LocatorClusterManagementService.
Note the configuration managers are run on the locators.
CacheConfigurationManager
To extend this class, you will need to implement a few methods, basically to tell the framework how your element will be added/deleted/updated/found in the CacheConfig (an object represent the cache.xml). You can see examples in RegionConfigManager. In there you find yourself in need of a ConfigurationConverter.
ConfigurationConverter
ConfigurationConverter specifies how you convert between your configuration object and the xml representation of it.
As we mentioned before, we don't use jaxb generated object as our configuration object but create our own configuration object. Since CacheConfig uses these jaxb-generated objects inside (because they are all auto-generated by the jaxb service), we will need a way to convert our configuration object to/from these xml objects. Hence, in order to implement the CacheConfigurationManager, we will need a converter first. You can also the usage and the implementation of a converter in RegionConfigManager.
ConfigurationManager
If your configuration is not part of the cache.xml, but something else, like deployment or runtime properties, you will need to implement this interface instead.
Configuration Validator
Configuration Validator is called when CMS receives the configuration for operations like create or delete. You can use this to validate if the attributes set on the configuration is valid or not.
For now, after you created a configuration validator, you will need to manually add it to the map in the list of validators in LocatorClusterManagementService.
Note the configuration validators are run on the locators.
Configuration Realizer
Configuration Realizer controls how the entity represented by this configuration is created/deleted/updated on the servers. For example, after we have this region configuration, how we actually create it on the servers. See RegionConfigRealizer.java for example.
For now, after you created a configuration realizer, you will need to manually add it to the map in the list of validators in CacheRealizationFunction
Note the configuration realizers are run on the servers.
A New Operation to be started by REST CMS
...