back to all blogsSee all blog posts

Dynamically update your microservice configuration

image of author
Neil Young on Sep 19, 2018
Post available in languages:

Most applications require configuration that is specific to the environment in which they run. Different environments require different configurations and it is highly desirable not to have to rebuild and repackage applications for each different case. MicroProfile Config allows you to separate configuration from microservices code so that the values required by the service can be maintained externally to the code. The configuration data can come from different locations and in different formats, for example from system properties and system environment variables.

For OpenLiberty customers the mpConfig-1.3 feature adds the Liberty server.xml file as a Config Source. This allows you to easily and dynamically change your application’s configuration by simply adding or modifying variables in your server.xml file. In addition, Liberty builds on previous versions of MicroProfile Config with enhancements in the areas of implicit converters and the mapping of config properties to environment variables. You can use this feature with either the cdi-1.2 feature or the cdi-2.0 feature.

To enable the MicroProfile Config 1.3 feature, add it to the server.xml:

<featureManager>
  <feature>mpConfig-1.3</feature>
</featureManager>

Define configuration in the server.xml

Define a MicroProfile application’s configuration through the Liberty server.xml file. Use the variable element in the server.xml to assign a value to a configuration entity that can be accessed by any application running on the server:

<variable name="varServerXMLKey1" value="valueinVarServerXMLVariable1" />

Alternatively, use the appProperties property element to assign a value to a configuration entity that can be accessed by a specific application:

    <application location="variableServerXMLApp.war">
        <appProperties>
             <property name="appServerXMLKey1" value="valueinAppProperties1"/>
        </appProperties>
    </application>

The appProperties element can be specified in either an application or a webApplication element.

Implicit converter improvements

The implicit converters have been improved so that if no built-in nor custom converter is available for a requested Type T, an implicit converter is automatically provided in any of the following situations:

  • The target type T has a public static T of(String) method.

  • The target type T has a public static T valueOf(String) method.

  • The target type T has a public Constructor with a String parameter.

  • The target type T has a public static T parse(CharSequence) method. This change means that some built-in converters were no longer required and have been removed.

See the GitHub issue: #325.

Mapping a config property to environment variable

Some operating systems allow only alphabetic characters or an underscore (_) in environment variables. Other characters such as period (.), forward slash (/), and so on may be disallowed. In order to set a value for a config property that has a name containing such disallowed characters from an environment variable, this ConfigSource searches 3 environment variables for a given property name (e.g. com.ACME.size) and the first environment variable found is returned:

  • Exact match (i.e. com.ACME.size)

  • Replace the character that is neither alphanumeric nor an underscore with an underscore (_) (i.e. com_ACME_size)

  • Replace the character that is neither alphanumeric nor an underscore with an underscore (_) and convert to upper case (i.e. COM_ACME_SIZE)

See the GitHub issue: #264.

Other changes

There were also some specification changes: #348, #325, #264.

The API bundle can work with either CDI 1.2 or CDI 2.0 in an OSGi environment.