The majority of applications need to be configured based on a running environment. It must be possible to modify configuration data from outside an application so that the application itself does not need to be repackaged.
The configuration data can come from different locations and in different formats (e.g. system properties, system environment variables, .properties, .xml, datasource). We call these config locations ConfigSources. If the same property is defined in multiple ConfigSources, we apply a policy to specify which one of the values will effectively be used.
Under some circumstances, some data sources may change dynamically. The changed values should be fed into the client without the need for restarting the application. This requirement is particularly important for micro services running in a cloud environment. The MicroProfile Config approach allows to pick up configured values immediately after they got changed.
There are a number of Config supporting projects, such as:
-
Netflix Archaius (https://github.com/Netflix/archaius)
-
DeltaSpike Config (http://deltaspike.apache.org/documentation/configuration.html)
-
Extracted parts of DeltaSpike Config (https://github.com/struberg/javaConfig/)
-
Apache Tamaya (http://tamaya.incubator.apache.org/)
A Config consists of the information collected from the registered ConfigSource instances.
These ConfigSources get sorted according to their ordinal.
That way it is possible to overwrite configuration with higher importance from outside.
The current configuration of an application can be accessed via ConfigProvider#getConfig().
A Config consists of the information collected from the registered org.eclipse.microprofile.config.spi.ConfigSource s.
These ConfigSource s get sorted according to their ordinal.
That way it is possible to overwrite configuration with lower importance from outside.
By default there are 3 default ConfigSources:
-
System.getProperties()(ordinal=400) -
System.getenv()(ordinal=300) -
all
META-INF/java-config.propertiesfiles on the ClassPath. (default ordinal=100, separately configurable via a config_ordinal property inside each file)
Therefore, the default values can be specified in the above files packaged with the application and the value can be overwritten later for each deployment.
It is possible to write and register a custom ConfigSources.
An example would be a ConfigSource which gets the configured values from a shared database table in a cluster.