AWS Mainframe Modernization Service (Managed Runtime Environment experience) will no longer be open to new customers starting on November 7, 2025. If you would like to use the service, please sign up prior to November 7, 2025. For capabilities similar to AWS Mainframe Modernization Service (Managed Runtime Environment experience) explore AWS Mainframe Modernization Service (Self-Managed Experience). Existing customers can continue to use the service as normal. For more information, see AWS Mainframe Modernization availability change.

Set up configuration for AWS Blu Age Runtime

The AWS Blu Age Runtime and the client code are web applications using the Spring Boot framework. It leverages Spring capabilities to supply configuration, with several possible locations and precedence rules. There are also similar precedence rules for supplying many other files, such as groovy scripts, sql, etc.

The AWS Blu Age Runtime also contains additional optional web applications, that can be opted-in if needed.

Application configuration basics

The default way to handle application configuration is through the use of dedicated YAML files to be supplied in the application server's config folder. There are two main YAML configuration files:

The first file configures the framework, i.e. Gapwalk-application.war, while the second one is for additional options specifically for the client application. This works with the use of spring profiles: the Gapwalk application uses the main profile, while the client application uses the profile profile.

The following example shows a typical main YAML file.

The following example shows a typical client YAML file.

For information about the content of the YAML files, see Enable properties for AWS Blu Age Runtime.

Application precedence

For these configuration files, Spring precedence rules apply. Notably:

For more information, see Official Spring Boot documentation.

JNDI for databases

The database configuration might be supplied with JNDI in the context.xml file in Tomcat. Any such configuration would override the YAML one. But pay attention that using this will not allow to wrap your credentials in a secret manager (see below).

The following example shows sample configurations for JICS and Blusam databases.

<Resource auth="Container" driverClassName="org.postgresql.Driver" initialSize="0" maxIdle="5" 
   maxOpenPreparedStatements="-1" maxTotal="10" maxWaitMillis="-1" name="jdbc/jics"
   poolPreparedStatements="true" testOnBorrow="false" type="javax.sql.DataSource" 		
   url="jdbc:postgresql://XXXX.rds.amazonaws.com:5432/XXXX" username="XXXX" password="XXXX" /> 

Other files (groovy, sql, etc.)

The other files used by the customer project use similar precedence rules as the ones for spring configuration. Examples:

All these locations can be overridden by way of a system property or a client YAML property.

If the property is not found, the files will be taken from the default location mentioned above. The lookup will first be done with the tomcat working directory as a root, and lastly in the application war file.

Additional web application

The AWS Blu Age Runtime contains additional web applications in its webapps-extra folder. These applications are not served by default by the tomcat server.

Opting-in to these web applications is modernization project dependent and is done by moving the desired war file from the webapps-extra folder to the webapps folder. After that, the war will be served by the tomcat server at next startup.

Some project-specific additional configuration can also be added in a YAML configuration file for each additional war, as is done in the application-main.yml file and explained above. The additional wars are: