Red Hat

WildFly 18 is released!

I’m pleased to announce that the WildFly 18 Final zip is now available for download.

This has been a very busy summer for the many folks who contribute to WildFly; a lot of long hours and a lot of progress. I’m forever grateful for the chance to work on a project with such a great group of people.

So, what have we been up to?

Jakarta EE and Java EE

As I announced last month, WildFly 17.0.1 was certified as a Jakarta EE 8 compatible implementation. As you would expect, WildFly 18 is compatible as well, with both the Full Platform and the Web Profile. Evidence supporting our certification is available here for Full Platform and here for the Web Profile.

WildFly 18 is also a certified compatible implementation of Java EE 8.

Besides ensuring WildFly is a compatible Jakarta EE 8 implementation, we put a lot of effort into better alignment with the Jakarta EE API projects, which I explain further below.

MicroProfile 3

In addition to the parts of MicroProfile that are also in EE 8, WildFly provides support for five other MicroProfile standards. For WildFly 18 we have upgraded those to the spec versions included in the MicroProfile 3.0 release:

Specification Version in WildFly 18

MP Config


MP Health Check


MP Metrics


MP OpenTracing


MP Rest Client


MicroProfile will be a significant focus for the next couple of WildFly releases. For WildFly 19 we are aiming to introduce support for the three remaining required MP 3 specs that we don’t currently support: MP JWT Authentication, MP Fault Tolerance and MP Open API.

Security Enhancements

WildFly 18 brings a number of enhancements in the security area:

Enhancements to the EE Subsystems

There are a number of new features provided by various WildFly subsystems that I’ll lump into the 'EE' category:

Clustering Enhancements

As always, the folks working on clustering have been busy as well:

  • For a clustered web app the JSESSIONID can now be encoded with multiple routes, ranked in order of preference. Thus, if the primary owner of a given session is inactive (from the load balancer’s perspective), the load balancer can attempt to route the request to the next route in the list. This ensures that requests will be directed to the next best worker in the event that the primary owner is inactive, and prevents requests from "spraying" across the cluster.

  • The Infinispan subsystem now exposes management metrics for remote HotRod caches.


WildFly in the Cloud

We’ve continued to make a lot of progress on the source-to-image (s2i) image for WildFly and on the WildFly Operator for Kubernetes/OpenShift. We’ll provide further details on what’s new there in the next couple of weeks when we announce new versions of those images based on the WildFly 18 server release.

Alignment with Jakarta EE API Projects

Besides ensuring we could certify as Jakarta EE 8 compatible, a lot of effort this summer went into further aligning with the Jakarta community. Specifically, WildFly incorporates a large number of component jars that provide the various EE APIs. For some EE specs WildFly directly provided jars produced by the various Java EE spec projects; for others the community has provided its own jars, derived from source from the Java EE spec projects. For both cases, for WildFly 18 we moved to align the source for our API jars with the source coming from the active Jakarta community.

  • For projects where we were directly shipping a jar from a Java EE 8 project, we switched to a jar from the equivalent Jakarta project. As a result the Maven groupId and artifactId of these artifacts has changed.

  • For projects where we were consuming an API jar produced by a community project, for all of those projects a new github repo was created, with the initial code derived from the Jakarta projects, and new releases were produced. For these APIs the Maven groupId and artifactId did not change (except for JTA, where we moved from the 1.2 version of the spec to 1.3, which affected the artifactId). The new releases have a maven version number one higher than the previous release, but this version bump solely reflects the new origin of the source code. It does not indicate major changes in the source itself.

It’s important to emphasize that the Jakarta EE 8 APIs are API identical to the Java EE 8 APIs and generally the method implementations are identical as well. So this change of the source from which we get the API jars is not expected to introduce any runtime incompatibility. This change is all about aligning the code we provide with projects that are actively maintained.

If you were compiling a deployment project against the Java EE 8 API artifacts we shipped in WildFly 17, that deployment should run fine on WildFly 18.

WildFly provides a number of maven boms for each release. These boms have been updated to use the Jakarta-based dependencies. In addition, the previous boms with maven ids and have been discontinued and new boms and have been introduced. Note that this name change does not indicate the WildFly 18 is not a Java EE 8 compatible server. We’re just aligning our names with Jakarta EE.

Within the WildFly runtime, deployments don’t concern themselves with the Maven GAV of the API jars we provide. To the extent a deployment is concerned at all about the details of how EE API classes are made visible (which would not be common), it would be interested in the names of the JBoss Modules modules that provide the spec classes. All of the existing EE API modules from WildFly 17 still exist in 18 — with the same names — and provide the equivalent APIs so there is no need for deployment authors to make any changes.

JDK 13

Our goal with WildFly is to have our releases run well for most use cases on the most recent GA JDK version available on the WildFly final release date. I’m pleased to report that this is the case with WildFly 18 and JDK 13. By run well, I mean the main WildFly testsuite runs with no more than a few failures in areas not expected to be commonly used. We want developers who are trying to evaluate what the latest JVM means for their applications to be able to look to WildFly as a useful development platform.

While we do want to run well on the most recent JDK, our recommendation is that you run WildFly on the most recent long-term support release, i.e. on JDK 11 for WildFly 18. We do considerably more testing of WildFly itself on the LTS JDKs, and we make no attempt to ensure the projects producing the various libraries we integrate are testing their libraries on anything other than JDK 8 or 11.

WildFly 18 also is heavily tested and runs well on Java 8. We plan to continue to support Java 8 at least through WildFly 21, and probably beyond.

Please note that WildFly runs on Java 11 and later in classpath mode.

At this point it is uncertain whether we’ll be able to say that the release of WildFly that follows JDK 14 going GA will run well on 14. We’ll have to see how well the work for that, both in WildFly itself and in the projects we integrate, aligns with our other goals for that release.

Jira Release Notes

The full list of issues resolved is available here. Issues resolved in the WildFly Core 10 releases included with WildFly 18 are available here.

Enjoy, and as always, thank you so much for your support of WildFly!

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!

back to top