Mastering Galleon Layers with JBoss EAP 8.1 Beta: A Practical Guide for Jakarta EE Developers

Provisioning lightweight, Bootable JAR-based Jakarta EE servers using Galleon layers and the EAP Maven Plugin.

Modern enterprise applications require more than just a Java runtime: They need tailored, efficient, and manageable runtime environments that fit specific operational constraints. With JBoss EAP 8.1 Beta, Red Hat brings a provisioning model powered by Galleon that enables developers to fine-tune application servers with surgical precision.

In this article, I'll explore:

• What Galleon is and why it's a game-changer.

• How to use Galleon Layers to provision a trimmed, production-ready JBoss EAP 8.1 runtime.

• How to evolve a Jakarta EE application to use the EAP Maven Plugin for provisioning and Bootable JAR packaging.

• Real-world memory and size savings with trimmed EAP servers.

Whether you're a seasoned Java EE architect or just transitioning to EAP 8.1, this guide will walk you through how to take control of your application runtime with Galleon layers.

What is Galleon?

Galleon is a provisioning tool developed by the WildFly community that allows developers to create custom application server distributions tailored to their specific needs. Instead of relying on a monolithic server distribution that includes every possible feature, Galleon gives you the ability to include only the components your application actually requires.

This fine-grained control helps reduce the server’s size, minimize memory usage, and streamline performance. Galleon achieves this by working with feature-packs and layers. Feature-packs are modular collections of server capabilities such as web server support, JAX-RS endpoints, or management interfaces. Layers are named configurations that group specific capabilities from feature-packs in meaningful ways. With EAP 8.1-beta, Red Hat delivers officially supported Galleon feature-packs and pre-defined layers, making it easier for developers to assemble purpose-built, efficient runtimes. The result is a more maintainable and predictable server environment, especially in containerized or resource-constrained deployments..

Why Use Galleon with JBoss EAP?

By default, a full EAP server includes a large number of subsystems to support a broad range of enterprise use cases: messaging, clustering, web services, etc. But most applications only need a fraction of these.

With Galleon provisioning, you can:

• Shrink the installation size (from ~290MB to ~77MB).

• Lower memory usage (e.g., Metaspace used: from 76MB to 48MB).

• Improve startup time and performance.

• Package and deploy lightweight Bootable JARs.

This is especially important in modern deployment environments like Kubernetes and serverless platforms, where image size and cold-start times matter.

Project Overview: A Simple Jakarta EE JAX-RS Application

To demonstrate Galleon provisioning, I’ll start with a basic Jakarta EE application: a JAX-RS endpoint that can be deployed to a standard EAP 8.1 server.

I’ll evolve the project to:

1. Add the EAP Maven Plugin.

2. Provision a trimmed server using Galleon layers.

3. Package and run the app as a Bootable JAR.

Pre-requisites

Before you begin, ensure the following tools are installed:

• Maven 3.8+

• JDK 17 or 21 (JBoss EAP 8.1 supports both)

You also need access to the JBoss EAP 8.1 Maven repositories via a configured settings.xml file if not using a Red Hat subscription.

Step 1: Add the EAP Maven Plugin

The first step is to modify your pom.xml to include the EAP Maven Plugin. This plugin allows you to provision and package the EAP server alongside your application.

Here’s the plugin configuration:

<plugin>
  <groupId>org.jboss.eap.plugins</groupId>
  <artifactId>eap-maven-plugin</artifactId>
  <version>2.0.0.Beta1-redhat-00011</version>
  <configuration>
    <channels>
      <channel>
        <manifest>
          <groupId>org.jboss.eap.channels</groupId>
          <artifactId>eap-8.1</artifactId>
        </manifest>
      </channel>
    </channels>
    <feature-packs>
      <feature-pack>
        <location>org.jboss.eap:wildfly-ee-galleon-pack</location>
      </feature-pack>
    </feature-packs>
    <layers>
      <layer>ee-core-profile-server</layer>
    </layers>
    <galleon-options>
      <jboss-fork-embedded>true</jboss-fork-embedded>
    </galleon-options>
  </configuration>
  <executions>
    <execution>
      <goals>
        <goal>package</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Explanation:

• channels: Declares the eap-8.1 release stream so you always pull the correct, compatible versions.

• feature-packs: Pulls in the official WildFly EE feature pack, which includes Jakarta EE 10 features.

• layers: Specifies what parts of the server to include. We'll explore layers in more detail shortly.

• galleon-options: Improves reliability by forking provisioning tasks into separate processes.

Step 2: Choose the Right Galleon Layer

A Galleon layer is essentially a named bundle of server features. You choose layers based on your application needs. Here are a few examples:

A Galleon layer is a named bundle of server functionality that reflects a specific use case or application need. You can think of each layer as a modular piece of the server, defining a set of capabilities that are automatically included in your provisioned distribution.

For example, the ee-core-profile-server layer includes support for the Jakarta EE 10 Web Profile and is a good starting point for most modern applications. If your application requires RESTful endpoints, the jaxrs-server layer adds the JAX-RS subsystem. To enable lightweight EJB functionality, you can include the ejb-lite layer. For applications that need database connectivity and JNDI support, the datasources-web-server layer is available. You are not limited to a single layer; layers can be combined depending on your application's requirements. This modular approach lets you compose a server runtime that aligns precisely with your functional and operational needs, avoiding the cost and complexity of unused features.

You can stack multiple layers, like:

<layers>
  <layer>jaxrs-server</layer>
  <layer>datasources-web-server</layer>
</layers>

In our example, ee-core-profile-server is enough since it includes JAX-RS.

Step 3: Build and Run the Provisioned Server

To build the provisioned server and deploy your application:

mvn clean package

This will:

• Provision a JBoss EAP 8.1 server with only the requested layers.

• Deploy the application into the target/server directory.

To start the server:

./target/server/standalone.sh

Memory and Size Savings: Full vs. Trimmed EAP

Let’s compare metrics between a full and trimmed JBoss EAP server.

Full EAP 8.1

• Installation size: 290MB

• Metaspace usage: 76MB

• Total heap used: ~395MB

Trimmed with Galleon Layers

• Installation size: 77MB

• Metaspace usage: 48MB

• Total heap used: ~135MB

These numbers represent a 73% reduction in disk footprint and significantly lower runtime memory use.

Step 4: Package as a Bootable JAR

For deployment in modern environments, packaging your app and runtime as a single executable JAR simplifies distribution.

To enable this:

Add to your eap-maven-plugin config:

<bootable-jar>true</bootable-jar>

Then run:

mvn clean package

You’ll get:

target/eap-jaxrs-bootable.jar

To run:

java -jar target/eap-jaxrs-bootable.jar

When Should You Use Bootable JARs?

Bootable JARs are particularly useful in modern deployment scenarios that demand simplicity and fast startup times. In container-based environments, where image layering and startup orchestration can introduce complexity, having a single executable JAR simplifies both the build and deployment process. CI/CD pipelines also benefit from Bootable JARs because they allow developers to generate a complete, self-contained runtime artifact that can be easily tested and deployed across environments.

Additionally, Bootable JARs are ideal for serverless platforms and edge computing, where cold-start latency is a concern and reducing the runtime's operational surface is crucial. Since the Bootable JAR packages both the application and the server runtime into a single file, it eliminates dependencies on external server configurations or startup scripts. This results in faster and more predictable deployments, with minimal overhead.

Advanced: Exploring More Galleon Layers

The full list of supported layers can be found in the JBoss EAP provisioning guide.

Some interesting options include:

• cloud-server: Adds cloud-native readiness (health probes, metrics).

• microprofile-platform: Enables MicroProfile Config, Fault Tolerance, Metrics.

• management: Includes admin console and management CLI.

• messaging-activemq: Includes JMS support.

To explore layers, you can run:

mvn org.jboss.galleon:galleon-cli:show-layers -Dfeature-pack=org.jboss.eap:wildfly-ee-galleon-pack

Conclusion

Galleon provisioning with JBoss EAP 8.1-beta provides a powerful mechanism to tailor your application server to exactly what your application requires. It enables you to eliminate unnecessary components, reduce memory usage, and streamline deployment with focused, production-grade runtime environments.

With just a few changes to your Maven configuration, you can move from a full-featured server distribution to a trimmed, efficient platform that integrates seamlessly with modern Java development practices. Packaging your application as a Bootable JAR further enhances portability and simplifies deployment, especially in containerized or cloud-native environments.

This provisioning model gives you control over your runtime architecture, aligns your application deployment with current DevOps and cloud standards, and prepares your Jakarta EE workloads for the next generation of enterprise Java. If you're building Jakarta EE applications today, now is the time to explore what EAP 8.1-beta and Galleon provisioning can do for your projects.

What's Next?

• Add CI/CD support to automatically produce provisioned artifacts.

• Explore integration with container image tools like JReleaser or Jib.

• Try combining Galleon provisioning with OpenShift deployment using Helm charts.

For more information, check out:

• JBoss EAP 8.1 Documentation

• WildFly Galleon Project

• Bootable JAR Reference Guide

Let your application dictate your server — not the other way around.