Red Hat

WildFly is Jakarta EE 8 Certified!

Tuesday was a great day in the world of enterprise Java. It’s been a long road since Jakarta EE was born following Oracle’s announcement that stewardship of Java EE would be moving to the Eclipse Foundation. But after a lot of hard work by folks in the Jakarta community, Jakarta EE 8 has been released. Congratulations to everyone involved with the Jakarta EE Platform project and all the various spec projects. The ability to enhance enterprise Java standards under an open-source model should bring great benefits to our communities.

I’m pleased to say that WildFly 17.0.1 has passed the Jakarta EE 8 TCK and our compatibility certification request has been approved by the Jakarta EE Spec Committee. So, WildFly is a Jakarta EE Full platform compatible implementation. We also remain a certified Java EE 8 compatible implementation.

My thanks to the many people whose work on WildFly and Jakarta EE made this certification possible, particularly to Scott Stark and Scott Marlow, who put in a lot of long days and nights on this. TCKs are not simple things, something you can now find out for yourself, as the move to Jakarta means the TCKs are all open source!

If you’re interested in the details of our certification request, they can be found at our certification repository.

Onward to WildFly 18!

WildFly 17.0.1 is released!

WildFly 17.0.1 Final is now available for download.

We had a number of important bug fixes ready to go so we decided to do a micro release for WildFly 17. I also wanted to blog a bit about using Galleon to update an existing Galleon-provisioned WildFly installation after a new release comes out.

Jira Release Notes

The full list of issues resolved in WildFly 17.0.1 is available here. Issues resolved in the WildFly Core 9.0.2 release included with WildFly 17.0.1 are available here.

Using Galleon to Update a WildFly Installation

As discussed in the WildFly 16 release announcement, you can use the Galleon tool to create a customized WildFly installation. Once you’ve done that, if a new WildFly release comes out you can use Galleon to update your installation. In this post I’ll walk through the basics of doing that.

If you want to follow along with the examples, download the latest Galleon command line tool, unzip it and add the bin dir to your PATH.

Feature Packs and Channels

The simplest command to install the latest version of WildFly into the directory my-wildfly is to call:

$ install wildfly:current --dir=my-wildfly

Most of that command is self-explanatory, but what about the wildfly:current part? That’s a feature-pack location or FPL. An FPL has a rich possible syntax, but most commonly you’ll see something simple like wildfly:current. This consists of two parts:

  • wildfly — the name of the feature pack

  • current — the name of a channel from which the feature pack should be consumed. A channel represents a source of backward compatible releases. A feature pack may be available over numerous channels, with different channels restricting which versions of the channel are available. The current channel for WildFly feature packs includes all versions.

Use the list-feature-packs command to see what packs and channels are available:

$ list-feature-packs
=============== ============== ============
Product         Update Channel Latest Build
=============== ============== ============
wildfly         current/final  17.0.1.Final
wildfly         17.0/final     17.0.1.Final
wildfly-core    current/final  9.0.2.Final
wildfly-core    9.0/final      9.0.2.Final
wildfly-servlet current/final  17.0.1.Final
wildfly-servlet 17.0/final     17.0.1.Final

Feature packs for wildfly, wildfly-core and wildfly-servlet are available, with wildfly-core and wildfly-servlet providing subsets of the traditional functionality of the WildFly application server. There are two channels for each, the current channel, which will have the latest release available, regardless of major/minor version, and then the 17.0 and 9.0 channels for wildfly/wildfly-servlet and wildfly-core respectively. The final in the Update Channel column for each channel indicates that the default frequency for the channel is final releases. This means that unless instructed otherwise by the user the Galleon tool when looking for releases from the channel will limit itself to final releases.

When provisioning a new server to which you anticipate applying updates when new versions come out, it’s good to consider which channel you want, as that will become the default place the Galleon tool looks for future updates. When doing an update you can specify the channel to use, but if you don’t do that, the channel associated with the installation will be used. So, if you don’t want your WildFly 17 installation accidentally updated to WildFly 18, use the 17.0 channel.

Installing and updating from the 17.0 Channel

This blog is about updating an installation to 17.0.1.Final, so first we want to install 17.0.0. I’m going to install a customized build that uses the cloud-profile plus standard management functionality.

$ install wildfly:17.0#17.0.0.Final --dir=my-wildfly --layers=cloud-profile,core-server,core-tools

Note the #17.0.0.Final in the FPL. I included this because by default Galleon would install the latest final version in the channel, i.e. 17.0.1.Final. Since this post is about updating to 17.0.1 I didn’t want to start there, so I added a specific feature pack version to the FPL. Normally you wouldn’t need to include that when provisioning a server.

The get-info command tells us the status of the installation:

$ get-info --dir=my-wildfly

======= ============ ==============
Product Build        Update Channel
======= ============ ==============
wildfly 17.0.0.Final 17.0

If I’m working inside a Galleon-provisioned installation, then I don’t need the --dir=my-wildfly in all the commands:

$ cd my-wildfly
$ get-info

======= ============ ==============
Product Build        Update Channel
======= ============ ==============
wildfly 17.0.0.Final 17.0

Use check-updates to find out if updates are available for an installation:

$ check-updates
Feature-packs resolved.
Some updates and/or patches are available.
======= ============= ============ ==============
Product Current Build Update       Update Channel
======= ============= ============ ==============
wildfly 17.0.0.Final  17.0.1.Final 17.0

And then, update to do the upgrade:

$ update

Galleon will prompt you with a y/n prompt to confirm. You can pass a --yes param to the update command to suppress this confirmation prompt.

I’ve observed that if I’m inside an installation directory and update it, for subsequent commands Galleon throws exceptions, until I maneuver out of the directory and back in.

$ get-info
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
Error occurred during initialization of VM
java.lang.Error: Properties init: Could not determine current working directory.
	at java.lang.System.initProperties(Native Method)
	at java.lang.System.initializeSystemClass(

$ cd ../my-wildfly/
$ get-info

======= ============ ==============
Product Build        Update Channel
======= ============ ==============
wildfly 17.0.1.Final 17.0

If for some reason you don’t like the result of a provisioning step, use the undo command to revert the most recent provisioning change (i.e. the update):

$ undo
$ cd ../my-wildfly/
$ get-info

======= ============ ==============
Product Build        Update Channel
======= ============ ==============
wildfly 17.0.0.Final 17.0

Finally, same as with the install command, you can provide the FPL of the feature pack to update. (Its dependencies will also be updated.) This can be useful, for example, if an installation was associated with the current channel but you want to be sure to only update to a WildFly 17 release.

$ update wildlfy:17.0 --yes

In that example I included the --yes param to tell Galleon to skip the y/n confirmation prompt.

Dealing with a modified installation

Of course in the real world you probably don’t provision a server, do nothing with it, and then update it. Instead, you probably modify the installation in some way after the initial install; e.g. add a deployment or use the CLI to change a configuration value. If you’ve done this, when you do an update, Galleon tracks the changes you have made and reapplies them.

This asciinema recording shows this kind of workflow in action. It also demonstrates the Galleon CLI’s interactive shell, where you can provide a series of commands without having to type all the time.

I start the recording after the initial provisioning.

Enjoy, and as always, thank you so much for your support of WildFly! And many thanks to Jean-Francois Denise for his help with this post!

WildFly 17 S2I image has been released on!

WildFly 17 S2I image on

Starting with WildFly 17, the WildFly S2I Docker image is now accessible from at this URL:

A companion image, a WildFly runtime Docker image that allows you to chain builds in OpenShift or use Docker multi stage builds, is available from:

For a complete documentation on how to use these images using s2i, OpenShift and Docker, refer to this documentation.

WildFly 17 S2I image and the WildFly Operator

Images built with WildFly 17 or 16 S2I image can be managed by the WildFly Operator.

Documentation on how to install the Operator and use it can be found in WildFly Operator.

WildFly S2I implementation notes

The WildFly S2I image that used to be developed in the repository openshift-s2i/s2i-wildfly is now developed in wildfly/wildfly-s2i repository.

This image offers the same features that were provided by the WildFly 16 image. In addition, during S2I build you have now the ability to provision a WildFly server using Galleon.

Documentation on how to configure S2I build and WildFly server execution can be found there.

Chaining builds with runtime image

In order to benefit from OpenShit chained builds or docker multi stage builds to build an application image that only contains what is required to execute WildFly (S2I tooling being removed), we have introduced a docker wildfly-runtime-centos7 image into which you can copy the WildFly server and deployed application from the WildFly S2I generated application image.

This OpenShift template automates the chained builds to output a smaller application image.

Adding imagestreams and template to OpenShift

At some point the new images will be made available from OpenShift catalog and image repository. You can already use these images by adding them yourselves to your OpenShift cluster.

NB: If you import the image streams in your project, be sure to set ImageStreams Namespace to your project namespace in the template. openshift being the default namespace.

back to top