Different flavors of WildFly

Beginning with the WildFly 22 release, the WildFly project began producing two variants of its landmark application server — the standard "WildFly" variant and the new "WildFly Preview".

The standard "WildFly" variant is the classic server that users have been familiar with for many years now. It’s a very mature server, with a lot of care taken to ensure new features are fully realized and to limit the number of incompatible changes between releases.

WildFly Preview is a tech preview variant of the server. The goal of WildFly Preview is to give the WildFly community a look at changes that are likely to appear in future releases of the standard WildFly server. The aim is to get feedback on in-progress work, so it is more likely that features will not be fully realized, and a greater number of incompatible changes may appear from release to release. The amount of testing WildFly Preview undergoes will generally not be as high as the standard WildFly variant.

The expectation is on any given release date, both standard WildFly and WildFly Preview will be released.

A WildFly Preview release will have the same version number and suffix (Beta, Final, etc) as the main WildFly release, but regardless of the suffix, a WildFly Preview release should be treated as a Technical Preview release.

1. Getting WildFly Preview

The zip or tar.gz file for WildFly Preview is available at https://wildfly.org/downloads right next to the main WildFly release files for the same version.

For bootable jar users and Galleon CLI users, we provide a Galleon feature pack for WildFly Preview. The Galleon feature pack location for the feature pack is wildfly-preview@maven(org.jboss.universe:community-universe). This feature pack is the WildFly Preview analogue to main WildFly’s wildfly@maven(org.jboss.universe:community-universe).

2. WildFly Preview and Jakarta EE

Prior to WildFly 27, the primary difference between standard WildFly and WildFly Preview was that standard WildFly supported Jakarta EE 8, while WildFly Preview supported Jakarta EE 9. However, beginning with the 27 release both standard WildFly and WildFly Preview support Jakarta EE 10, so this is no longer a difference between the two variants.

Note that formally certifying WildFly Preview as compatible implementation of Jakarta EE is not a priority for the WildFly project and may not happen at the time of a release, or ever. Users interested in formal EE compliance of WildFly Preview should check the WildFly Certifications repository.

2.1. WildFly Preview Support for EE 8 Deployments

The APIs that WildFly Preview exposes to deployments are the EE 10 APIs, so all the classes and interfaces are in the jakarta.* packages. But you may be able to run an existing EE 8 application on WildFly Preview.

What we’ve done is we’ve added to the server’s handling of managed deployments a bytecode and text file transformation process to convert EE 8 content into EE 9. It bytecode transforms deployment jars to alter references to EE 8 packages in the class file constant tables to change from javax.* to jakarta.*. The transformation goes beyond simple package renames; a number of other known differences between EE 8 and EE 9 are handled. We owe a great deal of thanks to the community behind the Eclipse Transformer project for their work on the underlying transformation tool.

As noted above, this handling is only applied to managed deployments. A managed deployment is one where a management client (the CLI, HAL console or the deployment scanner) presents deployment content to the server and the server makes a copy of it in its internal deployment content repository. The content that gets installed into the runtime is that internal copy. Unmanaged deployments that use EE 8 APIs will not work. We transform managed deployments when we copy the deployment content into the internal content repo. For unmanaged deployments we use the original content file(s) the user provides, and WildFly Preview won’t modify those files as we don’t regard them as being 'owned' by the server.

Note that the deployment transformation feature will not update the deployment to adapt to any API differences between Jakarta EE 9 and EE 10. It only covers the javax to jakarta name changes that came with EE 9.

In the long run it’s better for users if they either convert their application source to EE 10 APIs, or use build-time tooling that we expect the Jakarta ecosystem to provide over time to do transformation at build time. But some applications just can’t be changed, so the server-side solution WildFly Preview provides can handle those cases.

This deployment transformation feature will be removed from WildFly Preview in a future release. However it is likely that the WildFly developers will offer a separate Galleon feature pack that can be used to add this behavior into both standard WildFly and WildFly Preview.

3. Other Differences in WildFly Preview

WildFly Preview is intended to help get community exposure for other changes we plan to make in the server. Here are the key differencs between standard WildFly and WildFly Preview:

WildFly Preview is not a Jakarta EE 10 compatible implementation. It also is not a MicroProfile platform compatible implementation. Most EE 10 and MicroProfile applications are expected to run well on WildFly Preview, but it is not certified compatible.
The standard configuration files do not configure an embedded messaging broker. Instead, they configure the messaging-activemq subsystem to provide connections to a remote ActiveMQ Artemis broker. (It’s a task for the user to run such a broker or to update the config to integrate with a different broker.) We want WildFly out-of-the-box to be more of a cloud native appserver and having an embedded messaging broker in the default configuration is not cloud native. A WildFly container in the cloud running an embedded broker is not scalable, as multiple broker instances need separate configuration to act as a primary or backup. An embedded messaging broker also has more advanced persistent storage requirements than a server primarily dedicated to handling HTTP requests would have. Note however that running an embedded broker is still supported. We’ve added to the $WILDFLY_HOME/docs/examples/configs folder an example standalone-activemq-embedded.xml configuration showing its use.
The Hibernate ORM integration used by the JPA subsystem’s Hibernate Search feature supports using outbox polling as coordination strategy for automatic indexing.
The extensions providing the legacy subsystems 'cmp', 'config-admin', 'jacorb', 'jaxr', 'jsr-77', 'messaging' (HornetQ based), 'security' (not 'elytron'), and 'web' (not 'undertow') are removed. These were only used for domain mode to allow a Domain Controller to control hosts running much earlier WildFly versions where servers using these subsystems were supported.