Component configuration

Configurations in ADEPT2 are just Properties-objects which consist of key-value pairs. The configuration for a component is provided as a parameter of the component constructor. The contents of the configuration is up to the component itself. Therefore it should be documented as precisely as possible. In any case it should depict

Configuration files

Since configurations are just Properties-objects, they are stored in corresponding configuration files. To extend flexibility, every component (instance or type, c.f. type and instance configuration) can have its own configuration file. If this is the case, the path to this configuration file has to be stored in the corresponding registry (root) configuration. 
<InstanceName>.ConfigFile = <RelativePathOfConfigFile>
# configuration for type "ProcessManager" (configuration for anonymous
# instance and default configuration for all process manager-instances)
ProcessManager.ConfigFile = ProcessManager.properties
# configuration for (process manager) instance "PM1"
PM1.ConfigFile = pm1.properties
# configuration for (data manager) instance "DM1" in separate directory
DM1.ConfigFile = ./datamanager/data.properties

Configurations for components can also be stored directly in the root configuration. In this case the corresponding property (<ComponentType>.ConfigFile = <RelativePathOfConfigFile>) has to be omitted. Instead, all properties for the component have to be prefixed by the corresponding type name (for the component type and the anonymous instance) or prefixed by the corresponding instance name. 

<InstanceName>.ConfigFile = <RelativePathOfConfigFile>
# configuration for type "ProcessManager" in root configuration
ProcessManager.MaxTemplates = 1000
ProcessManager.MaxInstances = 100000
# configuration for (process manager) instance "PM1" in root configuration
PM1.MaxTemplates = 500
The prefixes are removed before the configuration is handed over to the component. The names of the properties after the prefix are user-defined except the configuration needed for the registry.

Mandatory keys

Some keys in the registry configuration are mandatory. Otherwise the registry can not handle the corresponding components appropriately. These are: In case anonymous instances are not enough, the configuration needs to contain the corresponding instance declarations: Example: 
# declaration of type "ProcessManager"
Components.ProcessManager = de.aristaflow.adept2.core.processmanager.ProcessManager
# implementation for anonymous instance of type "ProcessManager"
ProcessManager.Implementation = de.aristaflow.adept2.core.processmanager.transientprocessmanager.TransientProcessManager
# declaration of instance "PM1" and "PM2" of type "ProcessManager"
Instances.ProcessManager = PM1, PM2
# used implementation for "PM1"
PM1.Implementation = de.aristaflow.adept2.core.processmanager.defaultimplementation.ProcessManager
# PM2 uses the same implementation as the anonymous instance, no entry necessary

# declaration of type "DataManager"
Components.DataManager = de.aristaflow.adept2.core.datamanager.DataManager
# implementation for anonymous instance of type "DataManager"
DataManager.Implementation = de.aristaflow.adept2.core.datamanager.dbimplementation.DbDataManager
# only the anonymous instance exists, no instance declarations necessary

Configuration at runtime

As stated above, every component instance retrieves its configuration as the second parameter in its constructor. The first parameter of the constructor is the instance name as declared in the root configuration. The retrieved configuration contains all properties for the corresponding instance as well as the type configuration as defaults. For the previous example, this means, that the process manager instance "PM1" has the value 500 for MaxTemplates from its own configuration and 100000 for MaxInstances from the type configuration.
In case a separate configuration file is used, the key-value pairs are read and transferred to the component constructor. When using the root configuration of the registry, entries having the corresponding type or instance name as prefix are stored in a new Properties-object, their prefixes are removed and the created object is then transferred to the component constructor.

The component should check for the validity of the designated configuration in the constructor and throw a ConfigurationException if this is not the case. Otherwise failures due to erroneous configurations may occur later when the cause is hard to find.

Hierarchy of configurations

Configurations are plain Properties -instances. They provide a simple mechanism for default-values: Every Properties-instance can refer to another Properties -instance which is used as default. If a key-value-pair is not found in the referring Properties-instance, the request will be forwarded to the referred (default) Properties-instance.
This mechanism is provided by the Java runtime library and allows to have: The latter is achieved through different predefined directories where the configuration files are stored.

Configuration directories

There are three classes of configurations: default configurations, system configurations and user configurations. Each class is mapped to a specific directory containing the configuration files. User configurations overwrite (by the hierarchy of Properties) system configurations which overwrite default configurations. The configurations are searched in the following directories: