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
- which entries are mandatory (for the component),
- which entries are optional and
- which default values are used in case an entry is not present.
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.
Some keys in the registry configuration are mandatory. Otherwise the registry
can not handle the corresponding components appropriately. These are:
-
Components.<ComponentType>
Specifies the (complete) name of the interface (java interface or class) of
the component type.
-
<ComponentType>.Implementation
Specifies the (complete) name of a class implementing the corresponding type
interface. This can be the same class as the corresponding type interface in
case the latter is not defined via a java interface.
In case anonymous instances are not enough, the configuration needs to contain
the corresponding instance declarations:
-
Instances.<ComponentType>
Followed by a comma-separated list of (unique) instance names, this declares
these instances of the designated component type. The first name is the name
of the default instance. This is used for components that needs an instance
of the designated component type but has not explicitly declared a
corresponding usage relation.
-
<InstanceName>.Implementation
Specifies the (complete) name of a class implementing the interface of the
type of the declared (!) instance. This allows to have different
implementations for every component instance.
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.
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:
- specific instance configurations which have type
configurations as their default
- several configurations files with different priorities which
overwrite each other.
The latter is achieved through different predefined
directories where the configuration
files are stored.
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:
- default configuration:
The directory de/aristaflow/adept2/core/configuration/
relative to the classpath of the used Java Virtual Machine.
- system configuration:
Either
- the directories specified on the command line by using -Darflow.confdir=...
in the provided order (without overwriting) or
- the directory conf/ in the current directory if no
configuration directories are provided via command line.
- user configuration:
The directory .adept2 relative to the home-directory of the
current user.