Red Hat

WildFly and Jakarta EE 9

Congratulations to the Jakarta EE community for the recent great progress on Jakarta EE 9!

The Jakarta EE community has been making great strides in its work on Jakarta EE 9, and given today’s Jakarta EE 9 milestone release I wanted to give the WildFly community an update on what’s been going on regarding EE 9 in WildFly and a heads up on what I expect will be happening over the summer and the rest of this year.

As discussed in the Jakarta EE 9 Release Plan, EE 9 is primarily about implementing the necessary change in the Jakarta EE APIs from the javax.* package namespace to the jakarta.* namespace. It isn’t about bringing new functionality to end users; the focus is on providing a platform that all of us in the EE ecosystem can use to adapt to the namespace change, ensuring we’re all in a solid position to take advantage of new features and approaches to doing things that we’d like to see in EE 10.

The WildFly project is an important part of the EE ecosystem, so of course we’re going to participate in this. Besides work from WildFly community members on the Jakarta platform (big shout out to Scott Marlow for his TCK work) and the different specs, there’s been background prototyping work going on exploring how WildFly can provide an EE 9 compatible distribution. That work is now far enough along that it’s time to make it a part of the main WildFly development work.

The javax.* to jakarta.* transition is a big task and it’s going to take a while to percolate through our ecosystem. I don’t think it’s good for WildFly to stop providing new features and fixes to our community while we take this on, so I’d like WildFly’s primary distribution to continue to be based on the EE 8 APIs. I think this should continue to be the case until we begin work toward EE 10.

But we also need to provide an EE 9 server so our community can see what EE 9 will mean to them and so they can use us in their own EE 9 work. So I’d like us to begin producing a tech preview/beta EE 9 variant of WildFly. Ideally there would be at least one very early alpha type milestone over the summer but I don’t expect the first version to appear on the page until some time after the WildFly 21 release, perhaps late September or October. Then another version shortly after the WildFly 22 release, probably in December or early January. Eventually I’d like these to start coming out at the same time as the main WildFly releases.

The main goal of these is to allow people to adapt to the jakarta.* namespace change. However, I would also like them to serve as a bit of a preview for how we see WildFly evolving in the future. For example WildFly 21 will still have the legacy Picketbox-based security as the default security layer, but I’d prefer not to have that layer even be present in the EE 9 variant.

Although I’d like this EE 9 variant to be an evolution from what we have now, and a good way to adapt to the namespace change, it’s important to point out that any EE 10 variant of WildFly may evolve quite significantly from what we’ll be doing with EE 9. There is some uncertainty around how EE 10 will evolve and an expectation that EE 10 and Eclipse MicroProfile alignment will be a key focus, so what we’re doing with EE 9 is likely not going to align fully with our efforts in the future. We are working on getting this notion better codified.

WildFly is a huge codebase, so maintaining two completely distinct flavors of it is not feasible. Furthermore, for a long time at least some of the binaries we ship will have been compiled against EE 8 APIs, with no native EE 9 variant available. To make this work, the EE 9 server would be based on a separate Galleon feature pack from what we use for the main distribution. The large majority of the software artifacts that feature pack references will be the same as what’s in the EE 8 distribution. However, as part of provisioning, any EE 8 content in the server will be transformed (primarily bytecode transformation) to use the EE 9 APIs. Scott Marlow, Richard Opalka and Jean-Francois Denise, with much appreciated assistance from B.J. Hargrave and others on the Eclipse Transformer project, have been making good progress on the needed transformation technology, and Jean-Francois has done well with the needed Galleon tooling. Jean-Francois’s latest POC is able to provision a server that can pass a significant chunk of the WildFly testsuite. That’s a good sign that it’s time for this work to start surfacing in the main WildFly and WildFly Core repos.

Expect to hear more discussion, JIRAs, PRs, etc about this in the coming few weeks as we begin implementing changes in the main code base to make the EE 9 variant more maintainable and as development branches get underway. I’d love to hear your voices!

To be honest, when the need for the javax.* to jakarta.* transition came up last year I was dreading dealing with it, but now I think it will be a lot of fun. Part of the overall goal with what we’ve been doing with Galleon has been to make it easier for users to have the WildFly they want. That rightfully should include truly distinct flavors, not just different subsets of a single flavor. This EE 9 work is going to be a great opportunity for us to make progress on that goal.

Best regards,


WildFly 20 is released!

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?



As always, the folks working on security have been busy:


  • The standard way to configure stateful bean session timeout for each ejb is via a @StatefulTimeout annotation, or a stateful-timeout setting 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-store for 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 jaxrs subsystem) 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/examples directory to help users migrate a standalone configuration to one more like the standalone-microprofile.xml configuration 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.


The WildFly 20 documentation is available at the site.

Just a reminder, starting with WildFly 19 we shifted the location of the auto-generated documentation of the appserver management API from the 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

The full list of issues resolved is available here. Issues resolved in the WildFly Core 12 releases included with WildFly 20 are available here.


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!

WildFly 19.1.0 is released!

WildFly 19.1.0 Final is now available for download.

As we usually do between WildFly majors, we’ve done an update release to provide the WildFly community with important bug fixes and component upgrades that have become available. Typically these are micro releases, but this time we had one feature that we wanted to make available, so we changed the version to 19.1.0 and released a minor.

The feature is related to handling of SameSite cookie attributes. Undertow has added support for SameSite="None" cookie attributes and support for a new SameSiteCookieHandler that sets SameSite attributes on cookies that match a cookie name pattern. With this handler, web developers can remain compliant with the latest changes in some browsers.

To use the SameSiteCookieHandler, add a undertow-handlers.conf file to your WAR’s WEB-INF directory that includes a line like the following:


Valid values for the mode parameter are Strict, Lax or None, ignoring case. See RFC6265bis for more information on the meaning of these modes.

Further details, including other parameters you can use to configure the SameSiteCookieHandler, are discussed in the WFLY-13003 feature analysis document.

If you want to add the SameSite handler to your application without changing the application code, look into using a deployment overlay to add the `WEB-INF/undertow-handlers.conf' file to existing deployments.

The full list of issues resolved in WildFly 19.1.0 is available here. Issues resolved in the WildFly Core 11.1.0 release included with WildFly 19.1.0 are available here.

Note for Galleon Users

If you provisioned a WildFly server associated with the 19.0 channel, a simple Galleon update won’t update your installation to 19.1.0, as 19.1.0 is not part of that channel’s version range. There’s a new 19.1 channel that you’ll need to specify.

For example, if you’d originally provisioned your server like this:

$ install wildfly:19.0 --dir=my-wildfly --layers=jaxrs-server
Feature-packs resolved.
Feature-packs resolved.
Packages installed.
JBoss modules installed.
Configurations generated.
Feature pack installed.
======= ============ ==============
Product Build        Update Channel
======= ============ ==============
wildfly 19.0.0.Final 19.0

Then a simple update will do nothing:

$ update --dir=my-wildfly
Feature-packs resolved.
Up to date. No available updates nor patches.

To get the update change the channel to 19.1:

$ update --feature-packs=wildfly:19.1#19.1.0.Final --dir=my-wildfly
Feature-packs resolved.
Some updates and/or patches are available.
======= ============= ============ ==============
Product Current Build Update       Update Channel
======= ============= ============ ==============
wildfly 19.0.0.Final  19.1.0.Final 19.1

Proceed with latest updates [y/n]?
Feature-packs resolved.
Packages installed.
JBoss modules installed.
Configurations generated.

$ get-info --dir=my-wildfly

======= ============ ==============
Product Build        Update Channel
======= ============ ==============
wildfly 19.1.0.Final 19.1

I hope you enjoy WildFly 19.1. If you have any questions or feedback please find us at the WildFly forums.

back to top