Valid configuration value locations in the Liberty runtime

The following sections describe the valid configuration value locations in the Liberty runtime.

For the most recent information about using the Liberty MicroProfile Config, see the Open Liberty website and the Open Liberty MicroProfile Config guides.

Environment variables

All process environment variables are included in a MicroProfile Config API Config when default sources are requested to be included. Liberty exposes host process environment variables to the Java™ System.getenv() method and additionally adds in properties from the server server.env file that are then in turn available to the MicroProfile Config API. Environment variables are included at ordinal 300 priority.

Properties that are sourced from Liberty server.env are passed to the MicroProfile Config API implementation by using operating system environment variables. Only properties that have valid environment variable names in the host environment can be sourced from server.env. For example, Linux® environments do not support full stops (.) in environment variable names, so properties names like user.name are not supported in server.env.

System Properties

All Java System Properties available by way of System.getProperties() are included in a MicroProfile Config API configuration when default sources are requested to be included. Liberty adds properties from the server bootstrap.properties file to the Java System Properties. System Properties are included at ordinal 400 priority.

MicroProfile Config file locations

If requested to add default properties, the Microprofile Config API loads properties from ${CLASSPATH}/META-INF/microprofile-config.properties files by using either the Thread ContextClassLoader or a user supplied ClassLoader. For a Liberty application, the META-INF location might be a subdirectory at the root of a JAR or WAR file, or in a JAR in an EAR file's lib directory, or in a server-level shared library JAR. Property file sourced property values are loaded at ordinal 100 priority.

Java ServiceLoader loaded sources

Configuration sources can be programmatically registered by using the API documented at the MicroProfile Configuration project site. The Java ServiceLoader pattern can also be used to locate configuration source objects that are dynamically discovered and loaded at run time.

Configuration value scope

Configuration sources are loaded by way of ClassLoader code by using the loadResources() method and by way of the Java ServiceLoader pattern. Thus the scope of configuration values mirrors that of Java classes within Liberty. Configuration values from inside one application WAR file are generally not accessible in other WAR files even if these configuration values are part of the same EAR application assembly or server. Configuration can be shared across an EAR by placing a ${CLASSPATH}/META-INF/microprofile-config.properties in a JAR in the lib directory of the EAR. Configuration values can be shared across a Liberty server by placing them in the server.env file, or by using a library element in the server.xml file with a corresponding commonLibrary reference for applications that need to use the common configuration values.

Using server.xml as a dynamic config source

The mpConfig-1.3 feature gathers properties defined in the Liberty server's server.xml configuration file and makes them available to MicroProfile Config as follows,

A property that is specified in the variable element in a server.xml file is injectable into all applications in the server.
```
<variable name="varServerXMLKey1" value="valueinVarServerXMLVariable1>
```

Properties may alternatively be specified in an appProperties element scoped by application.

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

Properties specified in variable elements will be treated as MicroProfile Config properties with an ordinal of 500, while properties specified in appProperties elements in application elements will be treated as MicroProfile Config properties with an ordinal of 600.

Where duplicate properties are specified in a server.xml element, the last value specified will be used by MicroProfile Config, so, for example, if the following were specified:

<application location="serverXMLApp.war">
<appProperties>
<property name="serverXMLKey1" value="serverXMLValue1"/>
<property name="serverXMLKey1" value="serverXMLValue1a"/>  
<property name="serverXMLKey2" value="serverXMLValue2"/>
<property name="serverXMLKey3" value="serverXMLValue3"/>
<property name="serverXMLKey1" value="serverXMLValue1b"/>
<property name="serverXMLKey4" value="serverXMLValue4"/>  
</appProperties>    
</application>

Then, these values are set:

serverXMLKey1="serverXMLValue1b"
serverXMLKey2="serverXMLValue2"
serverXMLKey3="serverXMLValue3"
serverXMLKey4="serverXMLValue4"