Red Hat

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.

WildFly 17 is released!

I’m pleased to announce that WildFly 17 Final is now available for download.

A lot of effort in this last quarter has gone into using WildFly in cloud environments, which I’ll expand on more below, but first I wanted to touch on improvements we’ve made in the main WildFly server.

Clustering Improvements

Messaging Improvements

  • We’ve added support for messaging clusters behind http load balancers by disabling automatic topology updates on clients. (This allows the client to continue to address the load balancer rather than trying to communicate with the servers behind the load balancer.)

  • The timeout the embedded messaging broker uses for opening journal files is now configurable.

  • Configurability of connections to remote AMQ brokers has been enhanced.

Other Notable Items

WildFly in the Cloud

As we continue with our quarterly delivery model, a major focus continues to be on making WildFly as easy and productive as possible to use on the cloud, particularly on Kubernetes and OpenShift. Quite a lot has happened this past quarter:

First, there’s now a launcher allowing you to use WildFly as a backend runtime at !

Second, I’m very pleased to announce the first release of our WildFly Operator for Kubernetes/OpenShift. It’s available at — try it out! Or even better lend a hand at . This is a key step in making it easier to manage WildFly-based applications in the cloud, with more to come.

Finally, the Galleon-driven cloud image prototype work that Jean-Francois Denise described in March is making very good progress. It’s leading to the next generation of source-to-image (s2i) for WildFly. Later this week Jean-Francois will be uploading WildFly 17-based images to In the meantime, I encourage you to learn more about these efforts or even have a go at building the images yourself.

For those of you who have previously used the OpenShift s2i image for WildFly, please note that going forward development will be happening at the new source repo under the wildfly GitHub organization.

JDK 12 and 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 17 and JDK 12. By run well, I mean our main 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 their development platform. It may not always be possible to attain this goal, but it’s one we take seriously.

Although JDK 13 is still in the EA stages, Richard Opalka continues to informally test WildFly against the EA releases as they come out and he reports that it is working well.

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 16. We do considerably more testing on the LTS JDKs.

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

Please note that WildFly runs on Java 11, 12 and 13 in classpath mode.

Jira Release Notes

The full list of issues resolved is available here. Issues resolved in the WildFly Core 9 releases included with WildFly 17 are available here and here.

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

Zulip Chat

After HipChat got closed down earlier this year we evaluated a few alternative chat solutions. During this period we temporarily moved community discussions back to IRC (#wildfly on Freenode).

We found that Zulip worked well for us and have now settled on this as our main chat tool. Thanks to the people at Zulip for their open source license!

To join in, go to and sign up. The most obvious stream to join is #wildfly-users for user questions. If you want to get involved in development, or keep tabs on what we are up to, #wildfly-developers. We also have more specific streams for development of larger app server areas (e.g. #wildfly-elytron and #undertow).

back to top