WildFly 20 is released!
By Brian Stansberry
| June 08, 2020
I’m pleased to announce that the WildFly 20 Final zip is now available for download.
After the big push on Eclipse MicroProfile 3.3 for WildFly 19, the focus for WildFly 20 was more on bug fixing and component updates. Between WildFly Core and full WildFly we resolved well over 100 bugs and did over 90 component upgrades, most of which also brought bug fixes. These are challenging times for all of us, with a lot of disruption in our lives, and I’m very proud of how much the many people contributing to WildFly have gotten done over these last couple of months.
But, of course, it wasn’t all bug fixing! So, what else is new?
Enhancements
Security
As always, the folks working on security have been busy:
-
Instead of needing to first add a credential to a credential store in order to reference it from a credential-reference, WildFly 20 adds the ability to automatically add a credential to a previously defined credential store. Check out Farah Juma’s blog post for an introduction to this new feature.
-
The Elytron subsystem configuration was enhanced to allow the definition of a regex-based security role mapping mechanism. With this functionality it is possible for users to easily translate a list of roles (eg. *-admin, *-user) to simpler roles (eg. admin, user) without having to implement their own custom components.
-
It is now possible to make use of the IP address of a remote client when making authorization decisions.
EJB
-
The standard way to configure stateful bean session timeout for each ejb is via a
@StatefulTimeoutannotation, or astateful-timeoutsetting in ejb-jar.xml. But if these are not provided WildFly now provides the ability to configure a default global stateful bean session timeout for all deployed stateful beans. This feature is useful for deploying and configuring multiple stateful beans consistently in a server instance or a cluster. -
In a clustered environment where EJB timers are persisting to a shared database, applications may not want to rely solely on a periodic refresh of their timers before performing certain tasks. With WildFly 20 it is now possible to programmatically refresh EJB timers that use a
database-data-storefor persistence. -
A large amount of information about the EJBs in a deployment is now available via the server management API.
MicroProfile Integration
-
RESTEasy (integrated in WildFly via the
jaxrssubsystem) can now be configured using MicroProfile Config. In addition, the jaxrs subsystem now exposes servlet init parameters, filter init parameters and servlet context parameters to applications as MicroProfile Config config sources. -
An example CLI script has been added to the server’s
docs/examplesdirectory to help users migrate a standalone configuration to one more like thestandalone-microprofile.xmlconfiguration WildFly provides.
Standards Support
WildFly 20.0.0 is a Jakarta EE 8 compatible implementation, with both the Full Platform and the Web Profile. Evidence supporting our certification is available for the Full Platform and for the Web Profile.
WildFly 20 is also a compatible implementation of Java EE 8.
WildFly 20 is also a compliant implementation of the Eclipse MicroProfile 3.3 platform specification.
JDK Support
For the last couple of years we’ve worked to ensure our releases run well for most developer use cases on the most recent GA JDK version available on the WildFly final release date. Unfortunately, that came to an end with WildFly 19 and JDK 14. We haven’t had time to digest some of the package removals in JDK 14, particularly in the security area.
However, I do believe WildFly runs well on JDK 13. By run 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 the latest JVM means for their applications to be able to look to WildFly as a useful development platform. We do see a couple of test failures with JDK 13 when using the deprecated Picketlink subsystem and WS Trust
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 20. We do considerably more testing of WildFly itself on the LTS JDKs, and we make no attempt to ensure the projects producing the various libraries we integrate are testing their libraries on anything other than JDK 8 or 11.
WildFly 20 also is heavily tested and runs well on Java 8. We plan to continue to support Java 8 at least through WildFly 22, and probably beyond.
Please note that WildFly runs on Java 11 and later in classpath mode.
At this point it is uncertain when we’ll be able to say that a release of WildFly runs well on JDK 14 or later. We’ll have to see how well the work for that, both in WildFly itself and in the projects we integrate, aligns with our other goals. I don’t expect it to be a priority before WildFly 22.
Documentation
The WildFly 20 documentation is available at the docs.wildfly.org site.
Just a reminder, starting with WildFly 19 we shifted the location of the auto-generated documentation of the appserver management API from the wildscribe.github.io site to a make it part of the general documentation for a release. The WildFly 20 management API documentation is in the wildscribe section of the WildFly 20 docs.
Jira Release Notes
Enjoy!
I hope this post finds you and your loved ones all safe and well. Please give WildFly 20 a spin and give us your feedback!
