de.aristaflow.adept2.base.configuration (AristaFlow Business Process Platform API)

Class Summary
Class	Description
ConfigurationConstants	Configuration-related global constants for general use in configuration files.
ConfigurationDescriptionTools	Provides the functionality for the validation of `configuration description`s and configurations.
ConfigurationManager	This configuration manager handles configurations for components and services of the AristaFlow-System.
ConfigurationPropertyProvider	This provider extends a normal `PropertyProvider` to support configuration directories as URLs to load configuration files from, a directory to write configurations changed at runtime to, a directory to write the logs to and boolean flags for whether to load configuration files from bundles (jar-files containing the AristaFlow-components), whether to use debug logging while bootstrapping and whether to keep the registered log handlers.
ConfigurationValidator	A `ConfigurationValidator` can be specified in a `ConfigurationDescription` and (if specified) is used to validate a configuration at application startup without having to wait until the component (for which the configuration was intended) is instantiated.
GlobalProperties	This file provides direct access to the global properties of AristaFlow.
LoggerManager	This class initialises and configures console and file loggers (handler) for the central logging, that is logging based on class names.
PropertyProvider	This class provides global properties that are needed for the whole AristaFlow-platform.
ServletConfigurationPropertyProvider	A `ServletConfigurationPropertyProvider` provides the means to retrieve global properties and the variables to be substituted from system properties as well as the init parameter of a servlet configuration or of a servlet context.
SystemPropertyProvider	A `SystemPropertyProvider` provides the means to retrieve global properties and the variables to be substituted directly from system properties of the JVM.

Enum Summary
Enum	Description
ConfigurationConstants.CommunicationProtocol	The names for all supported communication protocols (which are equal to the instance names of the corresponding communication services).
Property.Type	The supported data types for

Exception Summary
Exception	Description
AbortServiceException	In case an `ADEPT2Service` cannot be initialised or started due to a major problem, an `AbortServiceException` may be raised.
ConfigurationException	A `ConfigurationException` will be thrown if an erroneous configuration is discovered.
IllegalConfigurationDescriptionException	An `IllegalConfigurationDescriptionException` is thrown if there's an inherent error in the `ConfigurationDescription` of a component.
PropertyNotSetException	Configuration exception thrown, if a required property is not set in the configuration.

Annotation Types Summary
Annotation Type	Description
ConfigurationDescription	Classes specified as implementation for a component type may be annotated with a `ConfigurationDescription`.
Property	The definition of a configuration property in a `ConfigurationDescription`.

Package de.aristaflow.adept2.base.configuration Description

ADEPT2 provides its own framework for managing components and their configurations.

ADEPT2-components

ADEPT2 components are to a large extent autonomous. This allows them to have their own configuration. Despite their autonomy, ADEPT2-components may or even need to use other components, for instance, a process manager needs a log manager for process execution logs and a data manager for handling data produced and consumed by process steps. The data manager itself also needs a log manager for logging data access. Therefore a flexible configuration for these usage-relations is needed. To relieve the component programmer from this complexity, all of it is handled by registries and configuration managers.

Registries provide component instances as needed by other components. The managed components are also implicitly configured by the registry as specified in the corresponding configuration file. Each registry has its own configuration manager to handle the appropriate configuration files.

Component types and instances

To enhance flexibility, one distinguishes between component types and component instances. A component type is specified by its interface. This may either be a Java class or a interface. Each component type may have arbitrary instances. An instance needs to have at least a class file implementing the interface of the type and a name. All of these is specified in configuration files and interpreted at runtime, resp. boot time.
The configuration of a process manager type and a corresponding instance may look like this:

# declaration of type "ProcessManager"
Components.ProcessManager = de.aristaflow.adept2.core.processmanager.ProcessManager
# declaration of instance "PM1" of type "ProcessManager"
Instances.ProcessManager = PM1
# used implementation for "PM1"
PM1.Implementation = de.aristaflow.adept2.core.processmanager.defaultimplementation.ProcessManager
# used data manager instance for "PM1"
PM1.DataManager = DM1
# plugin-type which "PM1" can use for logging
PM1.PluginType = LogManager

Type and instance configurations

Each instance can have its own configuration. To simplify configurations, a type can have a configuration of its own. This is used as default for the corresponding instances.

Anonymous instance

Additionally, one does not even need to declare instances. There is one instance per component type which always exists. This is called the anonymous instance. It has the same name as the corresponding type.

Name constraints

Component types and instances are identified and configured by their (arbitrary) names. These names have to be unique with respect to a registry.
The names have to be legal URI path names. It is best to only use alphanumeric characters. They must not contain characters relevant for a URI, for instance, '?', ':', '/'.
Component instances have two names: a simple name as declared in the configuration and a hierarchical name which is a path expression containing the component type followed by the simple name, for instance, "/ProcessManager/PM1".

ADEPT2-logging

All ADEPT2-components may use Java-logging for traceability of the internal functions and method calls. This logging is the only component which is not provided and configured in the usual way by a registry. This is because the logging needs to be available before a registry is initialised. Otherwise the registry itself can not log its own initialisation. Therefore logging is set up in the very first configuration file Boot.properties.