How to configure your deployed application

Edit online

By default, your application automatically externalizes variables that can be uniquely configured for each deployment. At runtime, the values for these variables are read from the environment variables set in the container. If no corresponding environment variable is found, the default value that is specified in the server.xml file is used.

However, if the variable represents sensitive data (such as passwords), no default value is provided in the server.xml file. In this case, the variable must be defined as an environment variable for the deployment to work properly.

Default variables

The default value that is defined for each variable matches the value that is collected during analysis.

An example of how variables are used in the server.xml file:

<httpEndpoint host="${httpEndpoint_host_1}" httpsPort="${httpEndpoint_secure_port_1}" id="defaultId"/>

An example of the default values set for these variables:

<variable defaultValue="*" name="httpEndpoint_host_1"/>
<variable defaultValue="9443" name="httpEndpoint_secure_port_1"/>

Sensitive data variables

Sensitive data values must be provided through environment variables.

An example of how sensitive data variables are used in the server.xml file:

<authData id="whydah1Node04/db2" password="${whydah1Node04_db2_password_1}" user="user1"/>

No default values are defined for sensitive data variables.

File-based transaction logging

Note: If your application is configured to use file-based transaction logging, it requires configuration changes to run in a container. Either remove the file-based transaction logging from the server.xml file or configure the container to have the appropriate storage.

Removing file-based transaction logging

You need to remove the transaction xml element from the server.xml file.

cd <MIGRATION_BUNDLE_HOME>/src/main/liberty/config

Remove the transaction xml element from the server.xml file.

Note: Your deployed application no longer has transaction logging or recovery.

Configuring file-based transaction logging in a container

When you deploy your application to containers, ensure that the transaction log directory path is located within a mounted external volume. If you deploy the application to Kubernetes, use a Persistent Volume that supports Read-Write Many access and does not cross data center boundaries.

For more information, see Transaction recovery in a cloud environment.

Memory-based session replication

Note: Memory-based session replication requires configuration changes to work properly in a container environment.

Configuring memory-based session replication in a container

Two solutions provide equivalent functionality for configuring memory-based session replication in a containerized application:

  • Solution 1: Session persistence with JCache (Liberty)
  • Solution 2: Session persistence to a database (Liberty or WebSphere Application Server traditional (base))

Solution 1: Session persistence with JCache (Liberty)

For equivalent functionality in Liberty, you can configure session caching by using JCache with Red Hat Data Grid, based on Infinispan. Alternatively, you can use Hazelcast or other JCache providers.

For instructions on configuring containers based on an official Liberty container image to use Red Hat Data Grid (Infinispan) or Hazelcast, see session caching in Open Liberty Images.

For instructions on enabling session caching in any Liberty server, including containers not based on an official Liberty container image, see Configuring Liberty session persistence with JCache.

Solution 2: Session persistence to a database (Liberty or WebSphere Application Server traditional (base))

An alternative solution to using JCache is to persist session data to a database.

The database solution is available for both Liberty and WebSphere traditional base: