Dynamically Update Your Microservice Configuration in the Liberty August Beta

Learn how to dynamically update your Java microservice configuration with MicroProfile Configuration in the open-source Liberty server config.

Laura Cowen

Aug. 10, 18 · Microservices Zone · Tutorial

Like (2)

Save

3.93K Views

Easily and dynamically update your Java microservice configuration by adding or modifying variables in the Liberty server configuration. Try out MicroProfile Config 1.3 in the August 2018 beta of WebSphere Liberty.

Thanks to your support for our regular beta program, we are able to release new Liberty features every few months. We recently released WebSphere Liberty 18.0.0.2, built on Open Liberty 18.0.0.2.

Look out for more betas over the coming months. If you just can't wait, take a look at the daily builds of Open Liberty.

Follow Open Liberty happenings on @OpenLibertyIO.

What's New in This Beta?

Dynamically update your microservice configuration with MicroProfile Config 1.3
Get it now!
Ask a question about the beta

Dynamically Update Your Microservice Configuration With MicroProfile Config 1.3

MicroProfile Config separates configuration from microservices so that applications can be configured differently when running in different environments. You can now easily and dynamically change your application's configuration by adding or modifying variables in the Liberty 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>

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

For more info:

What's Already in There?

The July Liberty beta included getting metrics about the fault tolerance of your Java microservices with MicroProfile Metrics integration with MicroProfile Fault Tolerance 1.1.

Looking for the Latest?

If you're visiting this post from the future and you're looking for the latest releases of Liberty, here are the links you're looking for:

Topics:

microservices, microprofile, tutorial, open source

Published at DZone with permission of Laura Cowen, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Comments