WildFly 26.1 is released!

By Brian Stansberry | April 14, 2022

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

As I discussed in my January WildFly Release Plans for 2022 post, the primary work being done by the WildFly developer community since the start of this year has been aimed toward a feature-boxed WildFly 27 release, with the main targeted feature being Jakarta EE 10 support in standard WildFly. But while WildFly 27 will be feature-boxed and release when ready, we did want to deliver one more feature release to our community on our existing roughly quarterly schedule. We also intend to remove Java SE 8 and Jakarta EE 8 support from WildFly 27, so we wanted to give our community one more feature release that still supports that SE / EE combination. Hence, WildFly 26.1

New Features

There are number of new features in this release:

Batch

A new management attribute execution-records-limit has been added to the batch job repository resources (both in-memory and JDBC based). When set, the job repository will never return more than the specified number of job execution instances. Setting this attribute is useful in situations when the job repository stores an unusually large number of job executions, which can cause delays during application deployments or out-of-memory errors when trying to display the list of executions in the Web Console.

JCA

The ability to configure the resource adapter validation log directory has been added. This allows administrators to see the results of the validation performed by IronJacamar.
The datasources subsystem allows the configuration of custom classes for datasource validation (exception-sorter, valid-connection-checker, stale-connection-checker). For each of these the ability to specify the name of the JBoss Modules module where the classes can be found has been added, removing the need to modify the WildFly internal module configuration to make them accessible.

JMS

Apache Artemis now deletes queues in an asynchronous way using a scheduled thread. The frequency at which queues marked to be deleted are effectively deleted is something users need to be able to configure. So we added a new address_queue_scan attribute to allow users to set the period between each deletion.

MicroProfile

The MicroProfile Config with SmallRye subsystem now supports using a directory as a root for several MicroProfile ConfigSource directories, removing the need to define several ConfigSource directories if they share the same parent directory.

Security

The Elytron client now provides a new java security provider that can be used to load a default SSL context. When you register this provider in your JVM with high enough priority, then all client libraries that use SSLContext.getDefault() will obtain an instance of the SSL context that is configured to be the default in the Elytron client configuration. This way you can make use of the Elytron client’s SSL context configuration without interacting with the Elytron API directly.
It is now possible to encrypt with a SecretKey the identities that are stored on the local filesystem when using an Elytron filesystem-realm. It is also possible to encrypt a filesystem realm that already exists to be compatible with these new changes.
The management operations exposed by the Elytron key store resources have been enhanced to improve readability of the read-alias output and to make read-aliases more versatile.

Java SE Support

You can run WildFly 26.1 or WildFly Preview 26.1 on any of the long-term support Java SE releases, including Java SE 17. We’ve tested WildFly heavily on Java SE 8, Java SE 11 and Java SE 17. Our testing included testing WildFly Preview on SE 17 with the massive Jakarta EE 9.1 TCK. (More on that in the 'Standards Support' section below.)

The most heavily tested SE options for WildFly are still SE 11 and SE 8, because both WildFly and its component library projects have so many years of testing on those versions.

While we recommend using an LTS JDK release, I do believe WildFly runs well on JDK 18. By runs 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 a newer JVM means for their applications to be able to look to WildFly as a useful development platform. Note that we make no attempt to ensure the projects producing the various libraries we integrate are testing their libraries on JDK 18.

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

Running WildFly with SE 17

Because SE 17 is probably new to a great many WildFly users, I’m continuing to copy over this next bit from the WildFly 25 release announcement.

One of the key differences in SE 17 versus the previous LTS SE 11 release is that the JVM will reject reflective access calls that SE 11 would only warn about, unless the JVM launch command includes JPMS configuration options to allow that access. WildFly does quite a bit of deep reflection, so part of our efforts in recent releases has been to identify the necessary JPMS settings. We have added those to our standard launch scripts, so WildFly should just work if you’re using those. The manifest file in a WildFly bootable jar will also include these settings. But some users may not be using a bootable jar or using our launch scripts to launch WildFly. For example many users use IDEs to launch WildFly and count on the IDE to provide arguments to the JVM. And IDEs may not be using the necessary settings yet.

If you are launching a WildFly instance on SE 17 and aren’t using a bootable jar or our launch scripts, here are the JPMS settings you will need:

--add-exports=java.desktop/sun.awt=ALL-UNNAMED
--add-exports=java.naming/com.sun.jndi.ldap=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.lang.invoke=ALL-UNNAMED
--add-opens=java.base/java.lang.reflect=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.security=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.base/java.util.concurrent=ALL-UNNAMED
--add-opens=java.management/javax.management=ALL-UNNAMED
--add-opens=java.naming/javax.naming=ALL-UNNAMED

Not all uses of the server will require all of those; the launch script sections that set those up include comments describing the main reason we’ve added each.

It’s possible your application may do something that requires additional JPMS settings; if so you can add those to the JVM launch command by editing the bin/standalone.conf or bin/domain.conf file or their .bat or .ps1 variants.

Standards Support

The standard WildFly 26.1.0 distribution is a Jakarta EE 8 compatible implementation, compatible with both the Full Platform and the Web Profile. Evidence supporting our certification is available for the Full Platform and for the Web Profile.

The standard WildFly 26.1 distribution is also a compliant implementation of the MicroProfile 4.1 platform specification. This has been demonstrated on SE 8, SE 11 and SE 17.

The WildFly Preview distribution released today is a compatible implementation of both the Jakarta EE 9.1 Web Profile and the Full Platform. WildFly Preview has been able to demonstrate compatibility while running on both Java SE 11 and on Java SE 17. Evidence supporting our certification is available for the Full Platform on SE 11, for the Web Profile on SE 11, for the Full Platform on SE 17 and for the Web Profile on SE 17.

The WildFly Preview 26.1 distribution is also a compliant implementation of the MicroProfile 5.0 platform specification. This, too, has been demonstrated on SE 8, SE 11 and SE 17.

Upcoming Changes

As discussed in my January WildFly Release Plans for 2022 post, WildFly 26.1 will be the last WildFly feature release that supports Java SE 8, Jakarta EE 8 and MicroProfile 4.1, while WildFly Preview 26.1 will be the last release that supports Jakarta EE 9.1. The WildFly 27 release will require Java SE 11 or higher and will support Jakarta EE 10 and MicroProfile APIs based on the jakarta.* package namespace.

As with other feature releases we’ve done for the last several years, we plan to do a WildFly 26.1.1 bug fix release about a month from now. Something different from previous releases is we also intend to do a WildFly 26.1.2 bug fix release in the July-August time frame. The aim of that release will be to deliver any critical fixes we’ve discovered, particularly security related items. We recognize that moving on from SE 8 and EE 8 may be a substantial task for many of our users, so we want to help ease that transition by providing an extra bug fix release.

Documentation

The WildFly 26.1 documentation is available at the docs.wildfly.org site. The WildFly 26.1 management API documentation is in the wildscribe section of the WildFly 26.1 docs.

Jira Release Notes

The full list of issues resolved is available in the WFLY JIRA project. Issues resolved in the WildFly Core 18.1 release included with WildFly 26.1 are available in the WFCORE JIRA project.

Enjoy!

Thank you for your continued support of WildFly. We’d love to hear your feedback at the WildFly forum.