Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Dynamically Update Your Microservice Configuration

DZone's Guide to

Dynamically Update Your Microservice Configuration

Learn how to easily and dynamically change your microservice app's configuration with MicroProfile Config.

· Microservices Zone ·
Free Resource

Learn how modern cloud architectures use of microservices has many advantages and enables developers to deliver business software in a CI/CD way.

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 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.

Discover how to deploy pre-built sample microservices OR create simple microservices from scratch.

Topics:
microservices ,configuration ,software architecture ,microprofile ,tutorial

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}