Chapter 4. Developing an application for the Thorntail runtime
This sections contains information about creating your application and configuring the Thorntail runtime for it.
4.1. Creating a basic Thorntail application
In addition to using a booster, you can create new Thorntail applications from scratch and deploy them to OpenShift.
4.1.1. Creating an application from scratch
Creating a simple Thorntail–based application with a REST endpoint from scratch.
Prerequisites
- JDK 8 or newer installed
- Maven 3.3.x or newer installed
Procedure
Create a directory for the application and navigate to it:
$ mkdir myApp $ cd myApp
We recommend you start tracking the directory contents with Git. For more information, see Git tutorial.
In the directory, create a
pom.xmlfile with the following content.<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>restful-endpoint</artifactId> <version>1.0.0-SNAPSHOT</version> <packaging>war</packaging> <name>Thorntail Example</name> <properties> <version.thorntail>2.2.0.Final-redhat-00021</version.thorntail> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <failOnMissingWebXml>false</failOnMissingWebXml> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <fabric8.generator.from>registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift:1.2</fabric8.generator.from> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>io.thorntail</groupId> <artifactId>bom</artifactId> <version>${version.thorntail}</version> <scope>import</scope> <type>pom</type> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>io.thorntail</groupId> <artifactId>jaxrs</artifactId> </dependency> </dependencies> <build> <finalName>restful-endpoint</finalName> <plugins> <plugin> <groupId>io.thorntail</groupId> <artifactId>thorntail-maven-plugin</artifactId> <version>${version.thorntail}</version> <executions> <execution> <goals> <goal>package</goal> </goals> </execution> </executions> </plugin> </plugins> </build> <!-- Specify the repositories containing RHOAR artifacts --> <repositories> <repository> <id>redhat-ga</id> <name>Red Hat GA Repository</name> <url>https://maven.repository.redhat.com/ga/</url> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>redhat-ga</id> <name>Red Hat GA Repository</name> <url>https://maven.repository.redhat.com/ga/</url> </pluginRepository> </pluginRepositories> <profiles> <profile> <id>openshift</id> <build> <plugins> <plugin> <groupId>io.fabric8</groupId> <artifactId>fabric8-maven-plugin</artifactId> <executions> <execution> <goals> <goal>resource</goal> <goal>build</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles> </project>Create a directory structure for your application:
mkdir -p src/main/java/com/example/rest
In the
src/main/java/com/example/restdirectory, create the source files:HelloWorldEndpoint.javawith the class that serves the HTTP endpoint:package com.example.rest; import javax.ws.rs.Path; import javax.ws.rs.core.Response; import javax.ws.rs.GET; import javax.ws.rs.Produces; @Path("/hello") public class HelloWorldEndpoint { @GET @Produces("text/plain") public Response doGet() { return Response.ok("Hello from Thorntail!").build(); } }RestApplication.javawith the application context:package com.example.rest; import javax.ws.rs.core.Application; import javax.ws.rs.ApplicationPath; @ApplicationPath("/rest") public class RestApplication extends Application { }
Execute the application using Maven:
$ mvn thorntail:run
Results
Accessing the http://localhost:8080/rest/hello URL in your browser should return the following message:
Hello from Thorntail!
After finishing the procedure, there should be a directory on your hard drive with the following contents:
myApp
├── pom.xml
└── src
└── main
└── java
└── com
└── example
└── rest
├── HelloWorldEndpoint.java
└── RestApplication.java4.1.2. Deploying an application to OpenShift
This procedure shows you how to:
- Build your application and deploy it to OpenShift using the Fabric8 Maven Plugin.
- Use the command line to interact with your application running on OpenShift.
Prerequisites
-
The
ocCLI client installed. - Maven installed.
- A Maven-based application.
Procedure
Log in to your OpenShift instance with the
occlient.$ oc login ...
Create a new project.
$ oc new-project MY_PROJECT_NAME
In a terminal application, navigate to the directory containing your application:
$ cd myApp
Use Maven to start the deployment to OpenShift.
$ mvn clean fabric8:deploy -Popenshift
This command uses the Fabric8 Maven Plugin to launch the S2I process on OpenShift and to start the pod.
Check the status of your booster and ensure your pod is running.
$ oc get pods -w NAME READY STATUS RESTARTS AGE MY_APP_NAME-1-aaaaa 1/1 Running 0 58s MY_APP_NAME-s2i-1-build 0/1 Completed 0 2m
The
MY_APP_NAME-1-aaaaapod should have a status ofRunningonce it is fully deployed and started. Your specific pod name will vary. The number in the middle will increase with each new build. The letters at the end are generated when the pod is created.Once your booster is deployed and started, determine its route.
Example Route Information
$ oc get routes NAME HOST/PORT PATH SERVICES PORT TERMINATION MY_APP_NAME MY_APP_NAME-MY_PROJECT_NAME.OPENSHIFT_HOSTNAME MY_APP_NAME 8080
The route information of a pod gives you the base URL which you use to access it. In the example above, you would use
http://MY_APP_NAME-MY_PROJECT_NAME.OPENSHIFT_HOSTNAMEas the base URL to access the application.Using
curlor your browser, verify your application is running in OpenShift.$ curl http://MY_APP_NAME-MY_PROJECT_NAME.OPENSHIFT_HOSTNAME/rest/hello Hello from Thorntail!
4.2. Deploying an existing Thorntail application to OpenShift
You can easily deploy your existing application to OpenShift using the Fabric8 Maven plugin.
Prerequisites
- A Thorntail–based application
Procedure
Add the following profile to the
pom.xmlfile in the root directory of your application:<profile> <id>openshift</id> <build> <plugins> <plugin> <groupId>io.fabric8</groupId> <artifactId>fabric8-maven-plugin</artifactId> <version>3.5.40</version> <executions> <execution> <goals> <goal>resource</goal> <goal>build</goal> </goals> </execution> </executions> <configuration> <generator> <includes> <include>thorntail-v2</include> </includes> <excludes> <exclude>webapp</exclude> </excludes> </generator> <enricher> <config> <thorntail-v2-health-check> <path>/</path> </thorntail-v2-health-check> </config> </enricher> </configuration> </plugin> </plugins> </build> </profile>In this profile, the Fabric8 Maven plugin is invoked for building and deploying the application to OpenShift.
- Deploy the application to OpenShift according to instructions in Section 4.1.2, “Deploying an application to OpenShift”.
4.3. Using Thorntail Maven Plugin
Thorntail provides a Maven plugin to accomplish most of the work of building uberjar packages.
4.3.1. Thorntail Maven plugin general usage
The Thorntail Maven plugin is used like any other Maven plugin, that is through editing the pom.xml file in your application and adding a <plugin> section:
<plugin>
<groupId>io.thorntail</groupId>
<artifactId>thorntail-maven-plugin</artifactId>
<version>${version.thorntail}</version>
<executions>
...
<execution>
<goals>
...
</goals>
<configuration>
...
</configuration>
</execution>
</executions>
</plugin>4.3.2. Thorntail Maven plugin goals
The Thorntail Maven plugin provides several goals:
- package
- Creates the executable package (see Section 5.2, “Creating an uberjar”).
- run
- Executes your application in the Maven process. The application is stopped if the Maven build is interrupted, for example when you press Ctrl + C.
- start and multistart
-
Executes your application in a forked process. Generally, it is only useful for running integration tests using a plugin, such as the
maven-failsafe-plugin. Themultistartvariant allows starting multiple Thorntail–built applications using Maven GAVs to support complex testing scenarios. - stop
Stops any previously started applications.
NoteThe
stopgoal can only stop applications that were started in the same Maven execution.
4.3.3. Thorntail Maven plugin configuration options
The Thorntail Maven plugin accepts the following configuration options:
- bundleDependencies
If true, dependencies will be included in the
-thorntail.jarfile. Otherwise, they will be resolved from$M2_REPOor the network at runtime.Property
swarm.bundleDependenciesDefault
true
Used by
package- debug
The port to use for debugging. If set, the swarm process will suspend on start and open a debugger on this port.
Property
swarm.debug.portDefault
Used by
run,start- environment
A properties-style list of environment variables to use when executing the application.
Property
none
Default
Used by
multistart,run,start- environmentFile
A
.propertiesfile with environment variables to use when executing the application.Property
swarm.environmentFileDefault
Used by
multistart,run,start- fractionDetectMode
The mode of fraction detection. The available options are:
-
when_missing: Runs only when no Thorntail dependencies are found. -
force: Always run, and merge any detected fractions with the existing dependencies. Existing dependencies take precedence. -
never: Disable fraction detection.
Property
swarm.detect.modeDefault
when_missingUsed by
package,run,start-
- fractions
A list of extra fractions to include when auto-detection is used. It is useful for fractions that cannot be detected or user-provided fractions.
The format of specifying a fraction can be: *
group:artifact:version*artifact:version*artifactIf no group is provided,
io.thorntailis assumed.If no version is provided, the version is taken from the Thorntail BOM for the version of the plugin you are using.
If the value starts with the character
!a corresponding auto-detected fraction is not installed (unless it’s a dependency of any other fraction). In the following example the Undertow fraction is not installed even if your application references a class from thejavax.servletpackage:<plugin> <groupId>io.thorntail</groupId> <artifactId>thorntail-maven-plugin</artifactId> <version>${version.thorntail}</version> <executions> <execution> <goals> <goal>package</goal> </goals> <configuration> <fractions> <fraction>!undertow</fraction> </fractions> </configuration> </execution> </executions> </plugin>Property
none
Default
Used by
package,run,start- jvmArguments
A list of
<jvmArgument>elements specifying additional JVM arguments (such as-Xmx32m).Property
swarm.jvmArgumentsDefault
Used by
multistart,run,start- modules
Paths to a directory containing additional module definitions.
Property
none
Default
Used by
package,run,start- processes
Application configurations to start (see multistart).
Property
none
Default
Used by
multistart- properties
See Section 4.3.4, “Thorntail Maven plugin configuration properties”.
Property
none
Default
Used by
package,run,start- propertiesFile
See Section 4.3.4, “Thorntail Maven plugin configuration properties”.
Property
swarm.propertiesFileDefault
Used by
package,run,start- stderrFile
A file path where to store the
stderroutput instead of sending it to thestderroutput of the launching process.Property
swarm.stderrDefault
Used by
run,start- stdoutFile
A file path where to store the
stdoutoutput instead of sending it to thestdoutoutput of the launching process.Property
swarm.stdoutDefault
Used by
run,start- useUberJar
If true, the
-thorntail.jarfile specified at${project.build.directory}is used. This JAR is not created automatically, so make sure you execute thepackagegoal first.Property
wildfly-swarm.useUberJarDefault
false
Used by
run,start
4.3.4. Thorntail Maven plugin configuration properties
Properties can be used to configure the execution and affect the packaging or running of your application.
If you add a <properties> or <propertiesFile> section to the <configuration> of the plugin, the properties are used when executing your application using the mvn thorntail:run command. In addition to that, the same properties are added to your myapp-thorntail.jar file to affect subsequent executions of the uberjar. Any properties loaded from the <propertiesFile> override identically-named properties in the <properties> section.
Any properties added to the uberjar can be overridden at runtime using the traditional -Dname=value mechanism of the java binary, or using the YAML-based configuration files.
Only the following properties are added to the uberjar at package time:
The properties specified outside of the
<properties>section or the<propertiesFile>, whose path starts with one of the following:-
jboss. -
wildfly. -
swarm. -
maven.
-
-
The properties that override a property specified in the
<properties>section or the<propertiesFile>.
4.4. Fractions
Thorntail is defined by an unbounded set of capabilities. Each piece of functionality is called a fraction. Some fractions provide only access to APIs, such as JAX-RS or CDI; other fractions provide higher-level capabilities, such as integration with RHSSO (Keycloak).
The typical method for consuming Thorntail fractions is through Maven coordinates, which you add to the pom.xml file in your application. The functionality the fraction provides is then packaged with your application (see Section 5.2, “Creating an uberjar”).
To enable easier consumption of Thorntail fractions, a bill of materials (BOM) is available. For more information, see Section 4.5, “Using a BOM”.
4.4.1. Auto-detecting fractions
Migrating existing legacy applications to benefit from Thorntail is simple when using fraction auto-detection. If you enable the Thorntail Maven plugin in your application, Thorntail detects which APIs you use, and includes the appropriate fractions at build time.
By default, Thorntail only auto-detects if you do not specify any fractions explicitly. This behavior is controlled by the fractionDetectMode property. For more information, see the Maven plugin configuration reference.
For example, consider your pom.xml already specifies the API .jar file for a specification such as JAX-RS:
<dependencies>
<dependency>
<groupId>org.jboss.spec.javax.ws.rs</groupId>
<artifactId>jboss-jaxrs-api_2.0_spec</artifactId>
<version>${version.jaxrs-api}</version>
<scope>provided</scope>
</dependency>
</dependencies>
Thorntail then includes the jaxrs fraction during the build automatically.
Prerequisites
-
An existing Maven-based application with a
pom.xmlfile.
Procedure
Add the
thorntail-maven-pluginto yourpom.xmlin a<plugin>block, with an<execution>specifying thepackagegoal.<plugins> <plugin> <groupId>io.thorntail</groupId> <artifactId>thorntail-maven-plugin</artifactId> <version>${version.thorntail}</version> <executions> <execution> <id>package</id> <goals> <goal>package</goal> </goals> </execution> </executions> </plugin> </plugins>Perform a normal Maven build:
$ mvn package
Execute the resulting uberjar:
$ java -jar ./target/myapp-thorntail.jar
Related Information
4.4.2. Using explicit fractions
When writing your application from scratch, ensure it compiles correctly and uses the correct version of APIs by explicitly selecting which fractions are packaged with it.
Prerequisites
-
A Maven-based application with a
pom.xmlfile.
Procedure
-
Add the BOM to your
pom.xml. For more information, see Section 4.5, “Using a BOM”. -
Add the Thorntail Maven plugin to your
pom.xml. For more information, see Section 5.2, “Creating an uberjar”. Add one or more dependencies on Thorntail fractions to the
pom.xmlfile:<dependencies> <dependency> <groupId>io.thorntail</groupId> <artifactId>jaxrs</artifactId> </dependency> </dependencies>Perform a normal Maven build:
$ mvn package
Execute the resulting uberjar:
$ java -jar ./target/myapp-thorntail.jar
Related Information
4.5. Using a BOM
To explicitly specify the Thorntail fractions your application uses, instead of relying on auto-detection, Thorntail includes a set of BOMs (bill of materials) which you can use instead of having to track and update Maven artifact versions in several places.
4.5.1. Thorntail product BOM types
Thorntail is described as just enough app-server, which means it consists of multiple pieces. Your application includes only the pieces it needs.
When using the Thorntail product, you can specify the following Maven BOMs:
- bom
- All fractions available in the product.
- bom-certified
-
All community fractions that have been certified against the product. Any fraction used from
bom-certifiedis unsupported.
4.5.2. Specifying a BOM for in your application
Importing a specific BOM in the pom.xml file in your application allows you to track all your application dependencies in one place.
One shortcoming of importing a Maven BOM import is that it does not handle the configuration on the level of <pluginManagement>. When you use the Thorntail Maven Plugin, you must specify the version of the plugin to use.
Thanks to the property you use in your pom.xml file, you can easily ensure that your plugin usage matches the release of Thorntail that you are targeting with the BOM import.
<plugins>
<plugin>
<groupId>io.thorntail</groupId>
<artifactId>thorntail-maven-plugin</artifactId>
<version>${version.thorntail}</version>
...
</plugin>
</plugins>Prerequisites
-
Your application as a Maven-based project with a
pom.xmlfile.
Procedure
Include a
bomartifact in yourpom.xml.Tracking the current version of Thorntail through a property in your
pom.xmlis recommended.<properties> <version.thorntail>2.2.0.Final-redhat-00021</version.thorntail> </properties>
Import BOMs in the
<dependencyManagement>section. Specify the<type>pom</type>and<scope>import</scope>.<dependencyManagement> <dependencies> <dependency> <groupId>io.thorntail</groupId> <artifactId>bom</artifactId> <version>${version.thorntail}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>In the example above, the
bomartifact is imported to ensure that only stable fractions are available.By including the BOMs of your choice in the
<dependencyManagement>section, you have:- Provided version-management for any Thorntail artifacts you subsequently choose to use.
-
Provided support to your IDE for auto-completing known artifacts when you edit your the
pom.xmlfile of your application.
Include Thorntail dependencies.
Even though you imported the Thorntail BOMs in the
<dependencyManagement>section, your application still has no dependencies on Thorntail artifacts.To include Thorntail artifact dependencies based on the capabilities your application, enter the relevant artifacts as
<dependency>elements:NoteYou do not have to specify the version of the artifacts because the BOM imported in
<dependencyManagement>handles that.<dependencies> <dependency> <groupId>io.thorntail</groupId> <artifactId>jaxrs</artifactId> </dependency> <dependency> <groupId>io.thorntail</groupId> <artifactId>datasources</artifactId> </dependency> </dependencies>In the example above, we include explicit dependencies on the
jaxrsanddatasourcesfractions, which will provide transitive inclusion of others, for exampleundertow.
4.6. Logging
4.6.1. Enabling logging
Each Thorntail fraction is dependent on the Logging fraction, which means that if you use any Thorntail fraction in your application, logging is automatically enabled on the INFO level and higher. If you want to enable logging explicitly, add the Logging fraction to the POM file of your application.
Prerequisites
- A Maven-based application
Procedure
Find the
<dependencies>section in thepom.xmlfile of your application. Verify it contains the following coordinates. If it does not, add them.<dependency> <groupId>io.thorntail</groupId> <artifactId>logging</artifactId> </dependency>
If you want to log messages of a level other than
INFO, launch the application while specifying theswarm.loggingsystem property:$ mvn thorntail:run -Dswarm.logging=FINE
See the
org.wildfly.swarm.config.logging.Levelclass for the list of available levels.
4.6.2. Logging to a file
In addition to the console logging, you can save the logs of your application in a file. Typically, deployments use rotating logs to save disk space.
In Thorntail, logging is configured using system properties. Even though it is possible to use the -Dproperty=value syntax when launching your application, it is strongly recommended to configure file logging using the YAML profile files.
Prerequisites
- A Maven-based application with the logging fraction enabled. For more information, see Section 4.6.1, “Enabling logging”.
- A writable directory on your file system.
Procedure
Open a YAML profile file of your choice. If you do not know which one to use, open
project-defaults.ymlin thesrc/main/resourcesdirectory in your application sources. In the YAML file, add the following section:swarm: logging:
Configure a formatter (optional). The following formatters are configured by default:
- PATTERN
- Useful for logging into a file.
- COLOR_PATTERN
- Color output. Useful for logging to the console.
To configure a custom formatter, add a new formatter with a pattern of your choice in the
loggingsection. In this example, it is calledLOG_FORMATTER:pattern-formatters: LOG_FORMATTER: pattern: "%p [%c] %s%e%n"Configure a file handler to use with the loggers. This example shows the configuration of a periodic rotating file handler. Under
logging, add aperiodic-rotating-file-handlerssection with a new handler.periodic-rotating-file-handlers: FILE: file: path: target/MY_APP_NAME.log suffix: .yyyy-MM-dd named-formatter: LOG_FORMATTER level: INFOHere, a new handler named
FILEis created, logging events of theINFOlevel and higher. It logs in thetargetdirectory, and each log file is namedMY_APP_NAME.logwith the suffix.yyyy-MM-dd. Thorntail automatically parses the log rotation period from the suffix, so ensure you use a format compatible with thejava.text.SimpleDateFormatclass.Configure the root logger.
The root logger is by default configured to use the
CONSOLEhandler only. Underlogging, add aroot-loggersection with the handlers you wish to use:root-logger: handlers: - CONSOLE - FILE
Here, the
FILEhandler from the previous step is used, along with the default console handler.
Below, you can see the complete logging configuration section:
The logging section in a YAML configuration profile
swarm:
logging:
pattern-formatters:
LOG_FORMATTER:
pattern: "CUSTOM LOG FORMAT %p [%c] %s%e%n"
periodic-rotating-file-handlers:
FILE:
file:
path: path/to/your/file.log
suffix: .yyyy-MM-dd
named-formatter: LOG_FORMATTER
root-logger:
handlers:
- CONSOLE
- FILE
4.7. Configuring a Thorntail application
You can configure numerous options with applications built with Thorntail. For most options, reasonable defaults are already applied, so you do not have to change any options unless you explicitly want to.
This reference is a complete list of all configurable items, grouped by the fraction that introduces them. Only the items related to the fractions that your application uses are relevant to you.
4.7.1. System properties
Using system properties for configuring your application is advantageous for experimenting, debugging, and other short-term activities.
4.7.1.1. Application configuration using system properties
Configuration properties are presented using dotted notation, and are suitable for use as Java system property names, which your application consumes through explicit setting in the Maven plugin configuration, or through the command line when your application is being executed.
Any property that has the KEY parameter in its name indicates that you must supply a key or identifier in that segment of the name.
Configuration of items with the KEY parameter
A configuration item documented as swarm.undertow.servers.KEY.default-host indicates that the configuration applies to a particular named server.
In practical usage, the property would be, for example, swarm.undertow.servers.default.default-host for a server known as default.
4.7.1.2. Setting system properties using the Maven plugin
Setting properties using the Maven plugin is useful for temporarily changing a configuration item for a single execution of your Thorntail application.
Even though the configuration in the POM file of your application is persistent, it is not recommended to use it for long-term configuration of your application. Instead, use the YAML configuration files.
If you want to set explicit configuration values as defaults through the Maven plugin, add a <properties> section to the <configuration> block of the plugin in the pom.xml file in your application.
Prerequisites
- Your Thorntail-based application with a POM file
Procedure
- In the POM file of your application, locate the configuration you want to modify.
Insert a block with configuration of the
io.thorntail:thorntail-maven-pluginartifact, for example:<build> <plugins> <plugin> <groupId>io.thorntail</groupId> <artifactId>thorntail-maven-plugin</artifactId> <version>{version}</version> <configuration> <properties> <swarm.bind.address>127.0.0.1</swarm.bind.address> <java.net.preferIPv4Stack>true</java.net.preferIPv4Stack> </properties> </configuration> </plugin> </plugins> </build>In the example above, the
swarm.bind.addressproperty is set to127.0.0.1and thejava.net.preferIPv4Stackproperty is set totrue.
4.7.1.3. Setting system properties using the command line
Setting properties using the Maven plugin is useful for temporarily changing a configuration item for a single execution of your Thorntail application.
You can customize an environment-specific setting or experiment with configuration items before setting them in a YAML configuration file.
To use a property on the command line, pass it as a command-line parameter to the Java binary:
Prerequisites
- A JAR file with your application
Procedure
- In a terminal application, navigate to the directory with your application JAR file.
Execute your application JAR file using the Java binary and specify the property and its value:
$ java -Dswarm.bind.address=127.0.0.1 -jar myapp-thorntail.jar
In this example, you assing the value
127.0.0.1to the property calledswarm.bind.address.
4.7.1.4. Specifying JDBC drivers for hollow JARs
When executing a hollow JAR, you can specify a JDBC Driver JAR using the swarm.classpath property. This way, you do not need to package the driver in the hollow JAR.
The swarm.classpath property accepts one or more paths to JAR files separated by ; (a semicolon). The specified JAR files are added to the classpath of the application.
Prerequisites
- A JAR file with your application
Procedure
- In a terminal application, navigate to the directory with your application JAR file.
Execute your application JAR file using the Java binary and specify the JDBC driver:
$ java -Dswarm.classpath=./h2-1.4.196.jar -jar microprofile-jpa-hollow-thorntail.jar example-jpa-jaxrs-cdi.war
4.7.2. YAML files
YAML is the preferred method for long-term configuration of your application. In addition to that, the YAML strategy provides grouping of environment-specific configurations, which you can selectively enable when executing the application.
4.7.2.1. The general YAML file format
The Thorntail configuration item names correspond to the YAML configuration structure.
Example 4.1. YAML configuration
For example, a configuration item documented as swarm.undertow.servers.KEY.default-host translates to the following YAML structure, substituting the KEY segment with the default identifier:
swarm:
undertow:
servers:
default:
default-host: <myhost>4.7.2.2. Default Thorntail YAML Files
By default, Thorntail looks up permanent configuration in files with specific names to put on the classpath.
project-defaults.yml
If the original .war file with your application contains a file named project-defaults.yml, that file represents the defaults applied over the absolute defaults that Thorntail provides.
Other default file names
In addition to the project-defaults.yml file, you can provide specific configuration files using the -S <name> command-line option. The specified files are loaded, in the order you provided them, before project-defaults.yml. A name provided in the -S <name> argument specifies the project-<name>.yml file on your classpath.
Example 4.2. Specifying configuration files on the command line
Consider the following application execution:
$ java -jar myapp-thorntail.jar -Stesting -Scloud
The following YAML files are loaded, in this order. The first file containing a given configuration item takes precedence over others:
-
project-testing.yml -
project-cloud.yml -
project-defaults.yml
4.7.2.3. Non-default Thorntail YAML configuration files
In addition to default configuration files for your Thorntail-based application, you can specify YAML files outside of your application. Use the -s <path> command-line option to load the desired file.
Both the -s <path> and -S <name> command-line options can be used at the same time, but files specified using the -s <path> option take precedence over YAML files contained in your application.
Example 4.3. Specifying configuration files inside and outside of the application
Consider the following application execution:
$ java -jar myapp-thorntail.jar -s/home/app/openshift.yml -Scloud -Stesting
The following YAML files are loaded, in this order:
-
/home/app/openshift.yml -
project-cloud.yml -
project-testing.yml -
project-defaults.yml
The same order of preference is applied even if you invoke the application as follows:
$ java -jar myapp-thorntail.jar -Scloud -Stesting -s/home/app/openshift.yml

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.