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

  2. In the directory, create a pom.xml file 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>
  3. Create a directory structure for your application:

    mkdir -p src/main/java/com/example/rest
  4. In the src/main/java/com/example/rest directory, create the source files:

    • HelloWorldEndpoint.java with 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.java with 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 {
      }
  5. 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.java

4.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 oc CLI client installed.
  • Maven installed.
  • A Maven-based application.

Procedure

  1. Log in to your OpenShift instance with the oc client.

    $ oc login ...
  2. Create a new project.

    $ oc new-project MY_PROJECT_NAME
  3. In a terminal application, navigate to the directory containing your application:

    $ cd myApp
  4. 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.

  5. 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-aaaaa pod should have a status of Running once 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.

  6. 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_HOSTNAME as the base URL to access the application.

  7. Using curl or 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

  1. Add the following profile to the pom.xml file 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.

  2. 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. The multistart variant allows starting multiple Thorntail–built applications using Maven GAVs to support complex testing scenarios.
stop

Stops any previously started applications.

Note

The stop goal 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.jar file. Otherwise, they will be resolved from $M2_REPO or the network at runtime.

Property

swarm.bundleDependencies

Default

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

Default

 

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 .properties file with environment variables to use when executing the application.

Property

swarm.environmentFile

Default

 

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

Default

when_missing

Used 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 * artifact

If no group is provided, io.thorntail is 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 the javax.servlet package:

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

Default

 

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

Default

 

Used by

package, run, start

stderrFile

A file path where to store the stderr output instead of sending it to the stderr output of the launching process.

Property

swarm.stderr

Default

 

Used by

run, start

stdoutFile

A file path where to store the stdout output instead of sending it to the stdout output of the launching process.

Property

swarm.stdout

Default

 

Used by

run, start

useUberJar

If true, the -thorntail.jar file specified at ${project.build.directory} is used. This JAR is not created automatically, so make sure you execute the package goal first.

Property

wildfly-swarm.useUberJar

Default

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.

Note

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.xml file.
Procedure
  1. Add the thorntail-maven-plugin to your pom.xml in a <plugin> block, with an <execution> specifying the package goal.

    <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>
  2. Perform a normal Maven build:

    $ mvn package
  3. Execute the resulting uberjar:

    $ java -jar ./target/myapp-thorntail.jar

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.xml file.

Procedure

  1. Add the BOM to your pom.xml. For more information, see Section 4.5, “Using a BOM”.
  2. Add the Thorntail Maven plugin to your pom.xml. For more information, see Section 5.2, “Creating an uberjar”.
  3. Add one or more dependencies on Thorntail fractions to the pom.xml file:

    <dependencies>
      <dependency>
        <groupId>io.thorntail</groupId>
        <artifactId>jaxrs</artifactId>
      </dependency>
    </dependencies>
  4. Perform a normal Maven build:

    $ mvn package
  5. Execute the resulting uberjar:

    $ java -jar ./target/myapp-thorntail.jar

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-certified is 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.

Note

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.xml file.

Procedure

  1. Include a bom artifact in your pom.xml.

    Tracking the current version of Thorntail through a property in your pom.xml is 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 bom artifact 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.xml file of your application.
  2. 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:

    Note

    You 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 jaxrs and datasources fractions, which will provide transitive inclusion of others, for example undertow.

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

  1. Find the <dependencies> section in the pom.xml file of your application. Verify it contains the following coordinates. If it does not, add them.

    <dependency>
      <groupId>io.thorntail</groupId>
      <artifactId>logging</artifactId>
    </dependency>
  2. If you want to log messages of a level other than INFO, launch the application while specifying the swarm.logging system property:

    $ mvn thorntail:run -Dswarm.logging=FINE

    See the org.wildfly.swarm.config.logging.Level class 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
Procedure
  1. Open a YAML profile file of your choice. If you do not know which one to use, open project-defaults.yml in the src/main/resources directory in your application sources. In the YAML file, add the following section:

    swarm:
      logging:
  2. 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 logging section. In this example, it is called LOG_FORMATTER:

    pattern-formatters:
      LOG_FORMATTER:
        pattern: "%p [%c] %s%e%n"
  3. Configure a file handler to use with the loggers. This example shows the configuration of a periodic rotating file handler. Under logging, add a periodic-rotating-file-handlers section 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: INFO

    Here, a new handler named FILE is created, logging events of the INFO level and higher. It logs in the target directory, and each log file is named MY_APP_NAME.log with the suffix .yyyy-MM-dd. Thorntail automatically parses the log rotation period from the suffix, so ensure you use a format compatible with the java.text.SimpleDateFormat class.

  4. Configure the root logger.

    The root logger is by default configured to use the CONSOLE handler only. Under logging, add a root-logger section with the handlers you wish to use:

    root-logger:
      handlers:
      - CONSOLE
      - FILE

    Here, the FILE handler 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.

Note

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
  1. In the POM file of your application, locate the configuration you want to modify.
  2. Insert a block with configuration of the io.thorntail:thorntail-maven-plugin artifact, 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.address property is set to 127.0.0.1 and the java.net.preferIPv4Stack property is set to true.

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
  1. In a terminal application, navigate to the directory with your application JAR file.
  2. 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.1 to the property called swarm.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
  1. In a terminal application, navigate to the directory with your application JAR file.
  2. 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:

  1. project-testing.yml
  2. project-cloud.yml
  3. 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:

  1. /home/app/openshift.yml
  2. project-cloud.yml
  3. project-testing.yml
  4. 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