Red Hat

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:

$ galleon.sh 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:

$ galleon.sh 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.

$ galleon.sh 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:

$ galleon.sh 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
$ galleon.sh 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:

$ galleon.sh 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:

$ galleon.sh 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.

$ galleon.sh 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(System.java:1166)

$ cd ../my-wildfly/
$ galleon.sh 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):

$ galleon.sh undo
$ cd ../my-wildfly/
$ galleon.sh 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.

$ galleon.sh 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 galleon.sh 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 quay.io!

WildFly 17 S2I image on quay.io

Starting with WildFly 17, the WildFly S2I Docker image is now accessible from quay.io at this URL: https://quay.io/repository/wildfly/wildfly-centos7

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: https://quay.io/repository/wildfly/wildfly-runtime-centos7

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 https://launch.openshift.io !

Second, I’m very pleased to announce the first release of our WildFly Operator for Kubernetes/OpenShift. It’s available at operatorhub.io — try it out! Or even better lend a hand at https://github.com/wildfly/wildfly-operator . 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 quay.io. 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!

back to top