Thorntail, previously called WildFly Swarm, is an open source implementation of MicroProfile specifications. It's built on top of mature technologies, and it leverages existing expertise that has been derived from Jakarta EE specifications, patterns, and implementations.
The Thorntail project was born with WildFly/Jakarta EE, but it focuses on modern cloud applications, following the path made by MicroProfile.io (in certain ways). It initially implemented version 1.3 of MicroProfile. You can find its specifications at https://github.com/eclipse/microprofile-bom/releases/download/1.3/microprofile-spec-1.3.pdf.
At the time of writing, Thorntail is in version 2.0.0, and it includes all of the features implemented in WildFly Swarm 2018.5.0.
You can consider Thorntail as a combination of all the benefits of the mature Java EE/Jakarta EE specifications and the flexibility of the MicroProfile.io and cloud-oriented concepts, as illustrated by the following diagram:
Indeed, when you build a traditional Jakarta EE application (distributed using the standard EAR or WAR), you need to install the entire application server (for example, WildFly), and then deploy your application on top of it.
It is true that with the introduction of the web profile (starting with Java EE 6), it is possible to decrease the number of APIs and components present in the initial configuration of the application server.
Further optimizations have been made by the application servers to only load the specifications (and consequently, the classes) that our application really needs. WildFly, for example, has four basic configuration profiles, which make up only a subset of the functionalities available during the start of the application server. WildFly also loads its subsystems in a lazy way, so that its footprint is very low, and the memory usage related to loaded classes is strictly related to what the application really uses.
However, in microservice architectures, this is not enough, because with a traditional Jakarta EE application server, you could have significantly more functionality than your application requires.
Thorntail gives you the ability to create a final package that contains exactly what you need for your deployment, using two different strategies, as follows:
- Uber JAR: A self-contained, executable Java archive that contains your application, the fractions of Thorntail required to support it, a Maven repository of dependencies, and a small library that's needed to bootstrap it all.
- Hollow Uber JAR: A self-contained, executable Java archive that contains no application code, but only what you need to run it. Usually, it contains a subset of APIs, Jakarta EE, and MicroProfile, that your application will use. In this way, you exclude your EAR or WAR file (with the application code) from the executable Hollow JAR. Then, you can deploy your application artifact in the same style as traditional Jakarta EE app servers.
One of the key elements of Thorntail is the fraction, which will be explained in the following section.
![]()
As we explained earlier, you can consider Thorntail as a runtime environment that you can build in a pluggable way. The core unit that represents the compositional aspect in Thorntail is the fraction. It's a well-defined runtime capability to add to your environment. In some cases, a fraction maps directly to a subsystem from WildFly, but in other cases, it may involve a different functionality that's described in the MicroProfile.io specifications or is needed in the cloud environment.
A fraction can do the following things:
- Directly enable a WildFly subsystem as Infinispan, which is needed to implement a data caching layer
- Integrate additional frameworks or services (for example, topology using Consul, JGroups, and OpenShift)
- Provide deployments of features like API documentation (for example, Swagger) or JMX metrics access (for example, Jolokia)
- Add API dependencies as Jakarta EE (for example, JAX-RS) or MicroProfile.io (for example, config, and health check)
- Alter deployment, introducing features as single-sign on for the authentication and authorization settings of your application (for example, Keycloak).
At the time of writing, there are about 184 fractions available that are stable and experimental, and there are more in the pipeline. About 80% wrap WildFly, related components, so you are able to use some Jakarta EE specifications, and you can easily evolve your application from a monolithic to a microservice architecture.
Fractions support explicit and implicit configuration; in many cases, you won't need to configure anything. The default values will let you successfully run your application.
Fractions can be detected or explicitly declared. The simplest case is a WAR project, with just the Maven plugin. After enabling the thorntail-maven-plugin inside your application, Thorntail will detect which APIs you use, and will include the fractions that implement them at build time. The default behavior of thorntail-maven-plugin is to auto detect fractions only if you do not specify anything explicitly. You can change this setting through the fractionDetectMode property.
To implement the auto detection mode, you should implement the following steps:
- 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>
- Specify the API that you want to u...
