WildFly 26 is released!
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.
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:
Take the address of the resource.
Remove the leading slash (
Append two underscores (
__) and the name of the attribute.
Replace all non-alphanumeric characters with an underscore (
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:
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:
Other New Features
The Elytron subsystem has added a new JAAS security realm type. The JAAS security realm can be used to configure custom Login Modules in the Elytron subsystem to use for credential verification. This is done by initializing and using a LoginContext from a provided JAAS configuration file to verify user’s credentials.
A WildFly domain mode
Host Controllercan now resolve standard server system properties when launching a managed server JVM. This makes it easier to configure shared server JVM settings at the domain, server-group or host level, while still having those settings incorporate server-specific path values. This is useful for things like adding GC logging to the server launch command, where the setting needs to include a server-specific location to write the log file.
There are a couple of compatibility topics that I want to highlight:
To build a Bootable JAR with WildFly 26, you will need to upgrade the Bootable JAR Maven plugin to the 6.1.1.Final or later release, preferably to 7.0.0.Final. The need to upgrade is a result of an important improvement in how the plugin can handle certain updates.
Some developers may be accustomed to exposing the H2 database web console during development work by adding servlets provided by WildFly’s
com.h2database.h2module in an application deployment. In WildFly 26 this no longer works out of the box. In standard WildFly (but not WildFly Preview), the ability to do this can be restored by following the instructions in the WildFly 26 documentation.
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:
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/domain.conf file or their .bat or .ps1 variants.
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.
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.
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.
Jira Release Notes
Thank you for your continued support of WildFly. We’d love to hear your feedback at the WildFly forum.