[[WildFly_and_WildFly_Preview]]
= WildFly and WildFly Preview
WildFly team;
:revnumber: {version}
:revdate: {localdate}
:toc: macro
:toclevels: 3
:toc-title: WildFly and WildFly Preview
:doctype: book
:icons: font
:source-highlighter: coderay

ifdef::env-github[]
:imagesdir: images/
:tip-caption: :bulb:
:note-caption: :information_source:
:important-caption: :heavy_exclamation_mark:
:caution-caption: :fire:
:warning-caption: :warning:
endif::[]

// ifndef::ebook-format[:leveloffset: 1]

(C) 2021 The original authors.

ifdef::basebackend-html[toc::[]]
:numbered:

= 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.

[WARNING]
====

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.
====

== Getting WildFly Preview

The zip or tar.gz file for WildFly Preview is available at link:https://wildfly.org/downloads[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)``.

== 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 https://github.com/wildfly/certifications/tree/EE10[WildFly Certifications repository].

=== 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 link:https://projects.eclipse.org/projects/technology.transformer[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.

== 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
link:Admin_Guide{outfilesuffix}#Messaging[`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.
* WildFly Preview includes a tech preview version of a new link:Admin_Guide{outfilesuffix}#Micrometer_Metrics[Micrometer subsystem].
* The Hibernate ORM integration used by the link:Developer_Guide{outfilesuffix}#JPA_Reference_Guide[JPA subsystem's] Hibernate Search feature supports using outbox polling as coordination strategy for automatic indexing.
* The `jaxrs` Galleon layer depends on (and thus brings in) the `microprofile-rest-client` layer. This dependency is optional, so it can be excluded when provisioning a custom WildFly Preview installation.
* RESTEasy Spring support only comes with WildFly Preview. Typically standard WildFly provides RESTEasy Spring support, but at the time of the WildFly 27 release the Spring libraries it integrates with had not yet
produced final releases. So to avoid possible incompatible changes in a future standard WildFly release, support
for RESTEasy Spring was moved to WildFly Preview only.
* 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.
* Alternate JPA and JSF providers that you can install with standard WildFly are not supported.
