WildFly 26 is released!

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

(Note that the release may not be available yet on Maven Central; please Maven Availability below for more details.)

There are number of new things in this release:

WildFly Preview and MicroProfile Platform 5

Last week the MicroProfile group announced the release of the MicroProfile 5.0 platform. Thanks and congratulations to the MicroProfile community!

MicroProfile 5.0 is mainly focused on updating APIs and dependencies from the use of Jakarta EE 8 and the javax.* namespace to EE 9.1 and the jakarta.* namespace.

As I announced when we released WildFly 22 Alpha1, along with our traditional Jakarta EE 8 distribution we want to give our users a preview of what will be coming in WildFly as we move on to EE 9 and later. We call this distribution "WildFly Preview". The WildFly 26.0.0.Final release includes an update to WildFly Preview. The current focus of WildFly Preview is on showcasing our efforts toward using the jakarta.* namespace and eventual Jakarta EE 10 support, so in the WildFly Preview 26 release we wanted to take advantage of the new developments in MicroProfile by demonstrating compatibility with MicroProfile 5.0. I’m very pleased to be able to say that WildFly Preview 26 is a compatible implementation of MicroProfile 5.0! Evidence supporting our certification is available on the WildFly certifications site.

My thanks to the MicroProfile working group for their efforts in getting MicroProfile 5.0 released, and to WildFly contributors Kabir Khan, Martin Stefanko and James Perkins for their hard work on integration of the 5.0 spec APIs and TCKs and on testing compliance.

To learn more about WildFly Preview, see the WildFly and WildFly Preview doc page. Please note that even though WildFly Preview 26 is coming from a .Final tag of the WildFly codebase, WildFly Preview should always be regarded as a tech-preview/beta distribution.

Cloud Configuration

WildFly now supports overriding the value of simple management attributes with environment variables. This allows you to tailor a huge range of settings to your runtime environment without needing to use multiple different configuration files for different environments or modify a common configuration file to add a lot of configuration expressions. This kind of configuration overriding can be useful anywhere, but particularly in cloud environments.

To override the value of a simple attribute of a management resource, you can specify an environment variable with the following conversion mapping:

  1. Take the address of the resource.

  2. Remove the leading slash (/).

  3. Append two underscores (__) and the name of the attribute.

  4. Replace all non-alphanumeric characters with an underscore (_)

  5. Transform to upper case.

For example, to set the value of the proxy-address-forwarding attribute to true on the /subsystem=undertow/server=default-server/http-listener=default resource, you can use the following environment variable:

export SUBSYSTEM_UNDERTOW_SERVER_DEFAULT_SERVER_HTTP_LISTENER_DEFAULT__PROXY_ADDRESS_FORWARDING=true

This feature is not activated by default. To activate this feature, you must set the WILDFLY_OVERRIDING_ENV_VARS environment variable on your target platform:

export WILDFLY_OVERRIDING_ENV_VARS=1

Other New Features

Compatibility Notes

There are a couple of compatibility topics that I want to highlight:

Java SE Support

You can run WildFly 26 or WildFly Preview 26 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.

As I noted in September’s Changes are coming to WildFly post, it is likely that WildFly will drop support for SE 8 in one of the next few releases. Eventually the transition to Jakarta EE 10 support and the expected minimum requirement for SE 11 by some of its API projects will drive WildFly to only support SE 11 or later. Early next year we’re aiming to nail down plans for when that will happen.

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 decided to copy over 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.0.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 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.

As discussed above the WildFly Preview 26 distribution is 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

WildFly 26 was the second in a series of a few releases where we’re expecting to make some big changes in the server. I encourage you to have a look at the Changes are coming to WildFly post that I mentioned above.

Maven Availability

As of the time I’m writing this, we’ve been experiencing issues with syncing artifacts initially deployed to the JBoss.org Nexus installation to Maven Central. This has affected WildFly 26 and a number of its component projects, so until this is resolved you may not find the WildFly 26 artifacts on Maven Central. The Maven repository url to use to pull WildFly from JBoss.org nexus is https://repository.jboss.org/nexus/content/groups/public/. The repository is easily accessed via a browser as well; for example the wildfly-dist artifacts can be found here.

Documentation

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

Jira Release Notes

The full list of issues resolved is available in the WFLY JIRA project. Issues resolved in the WildFly Core 18 release included with WildFly 26 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.