Hi folks, There's been quite a bit of progress recently on development of an EE 9 variant of WildFly so I'd like to provide an update. For context, the goal is to produce in Sept/Oct a tech-preview/beta/milestone release of a variant of WildFly that exposes EE 9 APIs, so the community can get a chance to try those out. Most of the implementation libraries in that release will use EE 8 APIs internally (javax.* packages instead of jakarta.*) so to make that work, when Galleon provisions an EE9 server it will bytecode transform any artifacts that use EE 8 APIs into ones that use EE 9 APIs. For deployments the server management layer will, when it reads in managed deployment content, transform EE 8 APIs to EE 9. This allows existing apps to work, which is particularly important for our testsuite, which is full of EE 8 apps. Thanks to a lot of hard work from Richard Opalka, Scott Marlow and Jean-Francois Denise and the folks on the Eclipse Transformer project I have a branch[2] that does this. It is based on the current WildFly master, but overrides most of the EE spec artifacts to use the ones that were included in the June EE 9 milestone release of Glassfish. It also overrides a few of the spec impls with native EE 9 artifacts that were used in that release. That branch adds a new "ee-9" maven with a few child modules, the most important of which are 'feature-pack' and 'dist'. The 'feature-pack' module produces a Galleon feature pack which is analogous to the wildfly-ee feature pack, but provides EE 9 APIs. The 'dist' module then builds a dist using that feature pack. At this point there is no EE 9 equivalent to the top level 'wildfly' feature pack, which adds in the Eclipse Microprofile JWT, Fault Tolerance and Open API specs. Dealing with those is a todo. If you do a normal 'mvn install' of this branch, the ee-9 modules will build. To run part of the testsuite against the EE 9 dist, do this: mvn install -Dts.ee9 -Dts.basic That runs testsuite/integration's 'smoke', 'web', 'ws' and 'basic' modules. Don't include -Dts.basic if you don't want the basic module to run. Not all tests run; some for known reasons, some for unknown ones. But a whole lot do. Over the course of the next few days I'll be working to get more testsuite modules to run with the ts.ee9 profile. Once that is done I'd like us to give some thought to producing an alpha release of WildFly so folks can more easily try this out. There are some important difference between this feature pack and the regular wildfly-ee one: 1) It does not depend on the wildfly-servlet feature pack. That feature pack IMO is a bit of a evolutionary appendix that serves little purpose in a Galleon driven architecture; it just adds complexity. So for this EE 9 feature pack I'm directly incorporating the content that would have been in wildfly-servlet, instead of having a dependency on an EE 9 variant of wildfly-servlet. It is tempting to do the same with the wildfly-core feature pack. Something to discuss. See [ <https://github.com/wildfly/wildfly/pull/13394>4] for more on this. 2) It does not include the legacy picketbox-based security subsystem. We want to move to a purely Elytron-based security architecture so legacy picketbox security is being left behind. This brings some interesting challenges, as it surfaces a few places where there's a default expectation for legacy security, with the user having to do work they shouldn't have to to make that go away. Darran Lofthouse has been looking at this. It also brings some effort on the testing side, just because quite a few tests expect legacy security. We've dealt with that before with running tests with pure elytron configs. Picketbox is still present, which means the security vault works, but I expect at some point that will be removed. Right now it was easier to leave it in place; otherwise it would have been removed as Picketbox is a barrier to using JDK 14 or later. 3) The default messaging subsystem config does not include an embedded JMS broker. Instead it is configured to point to a remote Artemis broker. Using an external broker is a more cloud-native way to deploy an app, which is why this variant is moving that way. The docs/examples/configs dir includes a standalone-activemq-embedded.xml config that provides the embedded broker. This definitely brings a big testing challenge as almost all of our tests involving messaging, including EJB MDB tests, assume the embedded broker is present. A quick workaround would be to run those against a server using the example standalone-activemq-embedded.xml config, but we also need to work out proper testing for the standard config that uses a remote broker. 4) The feature pack doesn't include various misc stuff that we either intended to prune from WF in general at some point (JSR77, picketlink extension, legacy subsystems that only provide domain-mode Domain Controller support for AS 7 hosts) or where it wasn't clear what we'd do so I left things behind just to reduce the initial scope (agroal, versions of Hibernate other than 5.3). 5) As noted above, this is equivalent to a wildfly-ee feature pack so it doesn't include MP FT, JWT or OpenAPI. 6) A 'thin server' (where JBoss Modules finds artifacts in maven, rather than in the local modules dir) does not work really well, as the transformed artifacts are not in the usual local or remote maven repos. There are things you can do in this area, but that's too much of an advanced case to get into here. Besides what I noted above there are some known issues, just in case you experiment and hit them: a) Transforming unmanaged EE 8 apps to EE 9 is not supported. This likely won't change for quite a while if ever. (Note: zipped apps deployed by the deployment scanner *are* managed apps. This limitation primary relates to exploded deployments.) b) The transformation of the jastow library needs improvement so the classes it generates from JSPs properly use the jakarta packages. c) The JSF impl doesn't properly provide a jsf.js file. I'm aiming to frequently merge master into this branch, so it keeps up to date with changes in master. It might make sense to create an ee-9 branch in the wildfly/wildfly github repo just to make it easier to coordinate updates, run CI etc. But for now I'm happy to receive PRs against this branch in my repo. I encourage people to give this a spin. If you're looking for things to do on this topic, please reach out to myself or Scott Marlow or Richard Opalka. There's plenty to do but this post is already way too long! Best regards, Brian [1] https://wildfly.org/news/2020/06/23/WildFly-and-Jakarta-EE-9/ [2] https://github.com/wildfly/wildfly/pull/13453 and https://github.com/bstansberry/wildfly/tree/ee-9 [3] https://github.com/wildfly/wildfly/tree/master/ee-feature-pack/galleon-fe... [4] https://github.com/wildfly/wildfly/pull/13394