WildFly 21 is released!
By Brian Stansberry
| October 13, 2020
I’m excited to announce that the WildFly 21 Final zip is now available for download.
Bootable JAR / Galleon Layers
The biggest thing in WildFly 21 is Jean-Francois Denise and the team have added GA-level support for the Bootable JAR feature that we’ve been working on over the last two releases.
The bootable jar feature allows you to add a maven plugin to your application’s pom and have your build package your application deployment and the WildFly server needed to run it inside a single executable jar file. Running your application can be as simple as java -jar my-application.jar.
A bootable jar can be particularly useful for cloud deployment use cases. For example, you can use the JKube maven plugin to build and deploy your application on OpenShift.
You can learn more about bootable jars in our new Bootable JAR Guide.
To get the most benefit from a bootable jar, you’ll want to customize the WildFly server in it provide only the functionality you need, while leaving out configuration and binaries that are not relevant. To support this kind of customization, the bootable jar maven plugin lets you specify a list of names of the WildFly functionality you’d like. Each of those names identifies one of the Galleon layers that WildFly provides.
To help ensure your experience with bootable jars is a good one, in WildFly 21 we greatly expanded the list of Galleon layers we provide. New in 21 are:
-
batch-jberet— Support for Jakarta Batch. -
ejb— Support for Jakarta Enterprise Beans, excluding the IIOP protocol. -
ejb-dist-cache— Infinispan-based distributed caching for stateful session beans. An alternative to the default local caching. -
ejb-lite— Support for Jakarta Enterprise Beans Lite. -
ejb-local-cache— Infinispan-based local caching for stateful session beans. An alternative to distributed caching. -
jdr— Support for the JBoss Diagnostic Reporting (JDR) subsystem. -
jsf— Support for Jakarta Server Faces. -
jsonb— Support for Jakarta JSON Binding. -
jsonp— Support for Jakarta JSON Processing. -
mail— Support for Jakarta Mail. -
messaging-activemq— Support for connections to a remote Jakarta Messaging Service broker. -
microprofile-platform— Support for all available Eclipse MicroProfile platform specifications. -
pojo— Support for legacy JBoss Microcontainer applications. -
remote-activemq— Support for connections to a remote Apache Activemq Artemis JMS broker. -
sar— Support for SAR archives to deploy MBeans. -
webservices— Support for Jakarta XML Web Services -
web-console— Support for loading the HAL web console from the /console context on the HTTP management interface.
More details along with the full set of layers WildFly provides is available in the bootable jar documentation.
There are now a variety of ways use WildFly: by unzipping the traditional server zip, by provisioning a customized WildFly instance using the Galleon CLI tool, and by building a running a bootable jar. We’ve added a brief Installation Guide to help you decide which approach best fits your needs.
Many thanks to Tomask Adamski, Tommaso Borgato, Yeray Borges, Fabio Burzigotti, Jean-Francois Denise, Vladimir Dousodil, Cheng Fang, Darragh Fitzmaurice, Emmanuel Hugonnet, Rado Husar, Bob Johnson, Jan Kasik, Darran Lofthouse, Jim Ma, Roberto Oliveira and James Perkins for all of your hard work on this this summer.
But, of course, we weren’t entirely focused on bootable jar and Galleon! So, what else is new?
Other Enhancements
Security
Once again, the folks working on security have brought us some new toys:
-
A RESTEasy client can now make use of Elytron’s configuration on the client side of a REST deployment to use credentials, bearer tokens and SSLContexts. For this to happen, the Elytron client artifacts must be present on the classpath during the build of RESTEasy client.
-
Users are now able to configure Elytron to use credentials established externally from the server to authenticate the client with HTTP. This will allow users to propagate authentication from mod-cluster/ajp to WildFly.
-
Two new kinds of Elytron security realms have been added:
-
A failover-realm is a security realm wrapper containing a delegate and a failover realm. If the delegate throws a RealmUnavailableException during identity lookup, it will be caught and failover realm will be used instead.
-
A distributed-realm is a security realm wrapper containing a list of other security realms allowing the server to sequentially invoke them until one succeeds.
-
-
It is now possible to use TLS 1.3 with WildFly when using the OpenSSL TLS provider with Elytron.
EJB
-
EJB invocations over the HTTP protocol can now be used in server-to-server configurations.
-
The EJB client protocol allows for compression of the invocation message and the open-session message payload. Configuration of such compression can now be configured globally.
Managing WildFly
-
WildFly’s MicroProfile Health implementation now includes three vendor-specific checks as part of server readiness checking. These check the management kernel’s view of the overall server status and the status of all deployments, and that the server booted without errors.
-
In the standalone.conf(.bat|.ps1) script configuration file you can now add a MODULE_OPTS=-javaagent:my-agent.jar environment variable. This allows you to take advantage of JBoss Modules' ability to run as a java agent invoke other agents. Taking advantage of this is useful for occasions when previously the log manager was required on the boot class path.
-
WildFly users can use a Git repository to manage their configuration file history of their standalone server. While previously it was only possible to establish a connection with HTTP authentication, it is now possible to establish a connection with SSH authentication using an Elytron configuration file to specify the credentials to be used.
Standards Support
WildFly 21.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 21 is also a compatible implementation of Java EE 8.
WildFly 21 is also a compliant implementation of the Eclipse MicroProfile 3.3 platform specification.
While we made a lot of progress on an EE 9 compatible variant of WildFly during the WildFly 21 cycle, I chose not to include a variant of that as part of the WildFly 21 release. I would like to produce an alpha of that fairly early during the WildFly 22 development cycle.
JDK Support
Our recommendation is that you run WildFly on the most recent long-term support JDK release, i.e. on JDK 11 for WildFly 21. While we do do some testing of WildFly on JDK 12 and 13, 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 21 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.
While we recommend using an LTS JDK release, 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 a newer 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.
Work to allow WildFly to run on JDK 14 and 15 is ongoing. We haven’t had time to digest fully some of the package removals that came in JDK 14, particularly in the security area. We did make significant progress in this area during WildFly 21 development though. The biggest barrier we face is the deprecated legacy security implementation based on Picketbox cannot support JDK 14. We intend to remove support for that security implementation after WildFly 23 and to only provide Elytron-based security. A lot of behind-the-scenes work to make that possible got accomplished during the WildFly 21 cycle.
Please note that WildFly runs on Java 11 and later in classpath mode.
Documentation
The WildFly 21 documentation is available at the docs.wildfly.org site.
As 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 21 management API documentation is in the wildscribe section of the WildFly 21 docs.
Jira Release Notes
Enjoy!
We hope you enjoy WildFly 21. Please give it a try, particularly the bootable jar features, and give us your feedback. But most important, please stay safe and well!
