//
// Copyright (c) 2016-2017 Contributors to the Eclipse Foundation
//
// See the NOTICE file(s) distributed with this work for additional
// information regarding copyright ownership.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
//
image:https://badges.gitter.im/eclipse/microprofile-config.svg[link="https://gitter.im/eclipse/microprofile-config"]

# Configuration for MicroProfile

## Status

MicroProfile Config Feature

== Rationale

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 microservices running in a cloud environment.
The MicroProfile Config approach allows to pick up configured values immediately after they got changed.

== Influences and History

There are a number of Config projects which directly influenced this proposal and acted as basis for this API, such as:

* 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/)

== Implementations

Microprofile Config does not contain an implementation itself but only provides the specified API, a TCK and documentation.

The following Implementations are available 

* Apache Geronimo Config (https://svn.apache.org/repos/asf/geronimo/components/config/trunk)
* WebSphere Liberty 2017 March-June Beta so far (https://developer.ibm.com/wasdev/)
* Payara Server 173 and Payara Micro 173 (https://docs.payara.fish/documentation/microprofile/config.html)
* WildFly / WildFly Swarm (https://github.com/wildfly-extras/wildfly-microprofile-config/)

== Design

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/microprofile-config.properties` files 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. A higher ordinal number takes precedence over a lower number.

== Custom ConfigSources

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.

== Building

The whole MicroProfile config project can be built via Apache Maven

`$> mvn clean install`

