WildFly 23 is released!
I’m pleased to announce that the WildFly 23 Final zip is now available for download.
It’s been a busy time since the January WildFly 22 release, with a bit shorter development cycle than normal. But a lot has been accomplished. Let’s have a look at what’s new.
In this release we have moved our MicroProfile platform implementations from the 3.3 platform specification versions to the 4.0 versions. WildFly 23 supports the following MicroProfile platform specifications:
|Specification||Version in WildFly 23|
MicroProfile Fault Tolerance
MicroProfile JWT Authentication
MicroProfile Rest Client
We also provide all of the MicroProfile specs that are also part of Jakarta EE 8.
Please note that an overarching goal of MicroProfile is to prioritize innovation over legacy compatibility. This may result in incompatible changes between specification releases, which WildFly will necessarily reflect. With MicroProfile 4.0 the following specifications include API incompatible changes:
MicroProfile Reactive Messaging
WildFly 23 now provides Tech Preview support for MicroProfile Reactive Messaging. This includes providing a connector for interaction with Kafka streams.
This capability adds support for two more MicroProfile specifications to WildFly, implemented via two new extensions and subsystems:
|Specification||Version in WildFly 23|
MicroProfile Reactive Messaging
MicroProfile Reactive Streams Operators
Please note that these extensions and subsystems are not included by default in the standard standalone.xml files that WildFly provides. Users who want them can add them to their configuration by using Galleon to provision a server or build a bootable jar and telling Galleon to include the new Galleon layers we’ve added for these. Or, use our zip and use the CLI to add the new extensions and subsystems. Further details can be found in the WildFly Admin Guide.
Expression Resolution from a Credential Store
WildFly 23 adds support for expressions in the management model to be encrypted using AES encryption and dynamically decrypted at runtime using a
SecretKey from a credential store.
This enhancement makes use of a new resource
expression-encryption in the
elytron subsystem to configure the expression resolution. This new resource also
contains a management operation
create-expression which allows users to create encrypted expressions using the usual management clients.
In addition to the new resource for expression resolution a new
secret-key-credential-store has been added for the purpose of providing an initial secret key to the application server process. In the past users needed to rely on masking a password but this was achieved using a well known public password and password based encryption. Starting from a secret key allows administrators to manage their own initial secret. Both this new credential store resource and the existing
credential-store resource have been updated to support the generation of secret keys as well as the ability to export and import previously generated secret keys.
wildfly-elytron-tool has also been updated to support both types of credential store and the
credential-store command updated to support
management of secret keys and the generation of encrypted tokens for use in expressions.
Users of the deprecated Picketbox-vault-backed expression resolution mechanism are strongly encouraged to move to this new feature, as our intent is to remove support for Picketbox and the Picketbox-vault in an upcoming release.
Provisioning and Managing WildFly
For users who wish to deploy multiple applications on the same server instance where one application during startup needs to make an external (i.e. over the network) invocation on another, we have provided a mechanism to turn off the default 'graceful startup' behavior that prevents such requests being accepted. Not handling such requests can prevent startup of the deployment making them and prevent the server booting. A number of users have asked for this use case tp be supported, so we have done so, but this is not a recommended deployment architecture. A server that is not booting gracefully may receive incoming requests that it is not yet ready to handle, resulting in errors.
There is now support for common script configurations. A common file can be used to set up the environment for all the shell scripts that WildFly provides. For example, you can set the JAVA_HOME in a common.conf script configuration file to ensure the same version of Java is used for all scripts.
When launching a WildFly bootable jar, users can instruct the bootable jar to execute an external CLI script as part of boot. This provides a mechanism for performing final configuration that cannot be accomplished via the preferred approach of configuring at build time or via typical runtime customization mechanisms like setting environment variables or system properties. This support is Tech Preview as the mechanism may change in later releases.
The management API can now be used to get a dump of the embedded Artemis broker’s journal for investigative purposes.
The behavior of the embedded Artemis broker’s critical-analyzer feature can now be configured.
The embedded Artemis broker can be configured to retain a corrupted journal file for subsequent investigation instead of immediately deleting it.
call-timeoutattribute has been added to the Jakarta Messaging core bridge configuration. The attribute specifies the time out for blocking calls performed by a core bridge.
The Jakarta Concurrency managed executors provided by the
eesubsystem can be configured to detect and automatically terminate tasks that have been executing for an unexpectedly long time. Such tasks can also be manually terminated.
transactionsubsystem now supports configuring a maximum timeout for transactions.
undertowsubsystem can now be configured to obfuscate the server instance-id data included as part of the request and response
Deployments can now depend on and use the APIs provided by the following Infinispan-related modules without getting a private API usage warning:
org.infinispan.client.hotrod(client for remote infinispan server)
Principal propagation of EJBs was different for legacy security and Elytron security in some cases. To provide a possibility to configure which behaviour should apply, we added a new attribute
application-security-domaincomponent in the
ejb3subsystem. This attribute is optional and the principal propagation is legacy compliant by default.
As I announced in November when we released WildFly 22 Alpha1, along with our traditional Jakarta EE 8 distribution we want to give our users a preview of what will be coming in WildFly as we move on to EE 9 and later. We call this distribution "WildFly Preview". The WildFly 23.0.0.Final release includes an update to WildFly Preview. Even though this is coming from a .Final tag of the WildFly codebase, WildFly Preview should always be regarded as a tech-preview/beta distribution.
EE 9 is primarily about implementing the necessary change in the Jakarta EE APIs from the javax.* package namespace to the jakarta.* namespace. This is a big change that is going to take a while to percolate through the EE ecosystem, e.g. for the many projects that compile against the EE APIs to provide versions that use jakarta.*. While this happens we want to continue to deliver new features and fixes to our community, so the primary WildFly distribution will continue to provide the EE 8 APIs.
Feature Pack Changes
WildFly users can use Galleon feature packs to provision a server or build a bootable jar. The WildFly project produces five different feature packs:
wildfly-preview. The composition of these feature packs has changed somewhat in WildFly 23, in that the
wildfly-ee feature pack no longer depends on
wildfly-servlet or (transitively)
wildfly-core. Instead it directly incorporates the same content that was previously made available via a dependency relationship. For most users, this subtle difference should have no impact. However, there are some cases where it might:
If you are producing your own feature pack that depends on
wildfly-eeyou may need to adjust your pom.xml and wildfly-feature-pack-build.xml to remove any dependency on wildfly-servlet and wildfly-core.
If your build uses another feature pack that depends on the
wildfly-eefeature packs, you should wait to upgrade to WildFly 23 until a release of that feature pack that depends on the WildFly 23 packs is available. A commonly used example of this is the
org.wildfly:wildfly-datasources-galleon-packfeature pack. Users of that feature pack should move to the 1.2.3.Final release that came out today.
The WildFly project still produces the
wildfly-servlet feature packs for those who wish to use them, although they may be discontinued at some point.
WildFly 23.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.
Beginning with WildFly 23 we will be exclusively focusing on the Jakarta EE test suite for EE certification / compliance.
WildFly 23 is also a compliant implementation of the MicroProfile 4.0 platform specification.
The WildFly Preview distribution released today is not yet a compatible implementation of Jakarta EE 9 or MicroProfile 4.0. We’re continuing to make good progress toward being able to certify compatibility, but we’re not there yet. The main area where users may hit meaningful issues related to EE compliance is in webservices if deployment descriptors using the EE 9 xml schemas are used. This can be worked around by using EE 8 schemas, which are functionally equivalent.
Our recommendation is that you run WildFly on the most recent long-term support JDK release, i.e. on JDK 11 for WildFly 23. 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 23 also is heavily tested and runs well on Java 8. We plan to continue to support Java 8 at least through WildFly 24, 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 15 and later is ongoing. We’re continuing our work to digest fully some of the package removals that came in JDK 14, particularly in the security area. 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 quite soon and to only provide Elytron-based security.
Please note that WildFly runs on Java 11 and later in classpath mode.
Jira Release Notes
Thank you for your continued support of WildFly. We’d love to hear your feedback at the WildFly forum.