CDP Configuration support is provided by a common framework to load and manage configuration properties from multiple sources. The basic concept is to load a set of default properties from a known resource file located on the class path, and then override these defaults with optional settings that can be provided by a user through either additional property files or via the command line (as VM arguments). The loading of defaults from a resource property file (named com/att/cdp/default.properties) ensures that values are defined for properties the application needs in order to operate.

One of these default values that can be set is the name of the property file that allows the user to supply settings, as well as the path where the file can be found. In general, the default name of the property file will be "cdp.properties", and the path that will be searched is "${user.home};etc;../etc". However, these values can be changed through the use of the default.properties resource file. The property that specifies the property file name is named com.att.cdp.bootstrap.file, while the property named com.att.cdp.bootstrap.path specifies the search path.

After the default.properties are loaded, but prior to searching for the application configuration file, the configuration factory checks for properties com.att.cdp.bootstrap.path and com.att.cdp.bootstrap.file in the System properties object (meaning they were set by the command line). If these values are defined in the system properties object, they are used. If not, these values are obtained from the default properties just loaded. This allows the specification of either the file name or path, or both, to be overridden during start up by using command-line arguments.

The search path is scanned for the first occurrence of the specified property file. The first occurrence is loaded and scanning is stopped at that point. The configuration factory does not load all occurrences it finds, only the first occurrence it finds.

The configuration properties are loaded and processed according to a defined precedence order, such that properties defined with a higher precedence override the same property at a lower precedence. The precedence order is defined as follows:

Precedence Order

1. Default properties are initially loaded into the configuration. These default properties are the lowest level precedence, and will be overridden by any properties specified at higher levels. These are loaded from resources that are packaged as part of the various application components. Each component (Server, Coordinator, EPM, or CLI) may have different default properties. The default properties are loaded from a resource named com/att/cdp/default.properties. The default properties can specify the name of the application property file to be used to configure the application, as well as the path to search. Additionally, these properties can be supplied via the command line to override the default settings if needed.
   
   
2. The configuration factory allows for the application to supply an initial properties object to initialize the configuration. This properties object could be loaded or created in any way necessary for the application. This is totally up to the application to define, if it is needed. If no application-specific property object is supplied, this step is skipped. If a property object is supplied, it is used to replace or set any properties that may have been defined by the defaults.
   
   
3. The configuration factory will then search for a bootstrap file on a bootstrap path. The actual bootstrap file name and path can be specified as properties on the command line, or will default to a file name of cdp.properties and a path of ${user.home};etc;../etc. If desired, the user can specify the exact name of the property file to be loaded as well as the path using -Dcom.att.cdp.bootstrap.file=<filename> and -Dcom.att.cdp.bootstrap.path=<path>. These properties are set to default values by the default properties loaded in step #1 above. The first occurrence of a property file is the file loaded and used. Any other occurrences are not processed.
   
   
4. The System properties are then merged into the configuration. This allows the highest level of precedence, command-line VM arguments (-Dname=value) to be merged into the configuration property object. These settings override all lower level settings of the same name, as well as merge all system properties into the configuration object.

Variables

The configuration support allows for variables to be inserted into any property that is defined. Variables are named using the format ${name}, where the "name" is the name of a property that is defined in the configuration, or a system property (such as user.home). Variables can nest, such that a variable can be replaced with another variable, which is then reevaluated to obtain the value. This allows for indirection as well as variable substitution, if needed.

Using the Configuration Support

The configuration support was designed to be easy to use. The configuration implementation is abstracted away from the application so that it could be changed easily in the future if needed, or if we needed to load different implementations for different reasons. This means that the application always accesses the configuration through an interface, named Configuration. The implementation of that configuration interface is obtained by a static method on the ConfigurationFactory class. The configuration factory will both create the configuration if not already created on the first access, as well as return the current configuration if already created. Additionally, the ConfigurationFactory provides mechanisms to recreate the configuration after the application is initialized should the need arise to update its configuration.

An example of the code needed to obtain access to the configuration is:

Configuration config = ConfigurationFactory.getConfiguration();

Please refer to the javadoc or the source code in cdp-common for other ways that the configuration and configuration factory can be used.

Reloading Properties

The configuration support allows for properties to be re-loaded and re-evaluated after the application is running. This is designed to allow a configuration to be refreshed should the need arise. This could allow on-demand refresh (via a command, for example), or automatically based on sensing a change in the configuration file.

When the ConfigurationFactory method getConfiguration(Properties) is called, the current configuration is cleared and rebuilt using the process defined above. The supplied property object is used in step #2 of the process. While the properties are being re-built, no access to the properties are allowed. Any attempt to access properties while the re-build operation is in effect will block the caller until completed. This is accomplished using read and write shared locks.