WildFly 23 is released!

By Brian Stansberry | March 11, 2021

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.

New Features

MicroProfile 4.0

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 Config

2.0

MicroProfile Fault Tolerance

3.0

MicroProfile Health

3.0

MicroProfile JWT Authentication

1.2

MicroProfile Metrics

3.0

MicroProfile OpenAPI

2.0

MicroProfile OpenTracing

2.0

MicroProfile Rest Client

2.0

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

1.0

MicroProfile Reactive Streams Operators

1.0.1

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.

Finally the 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.

Messaging

Other areas

  • The Jakarta Concurrency managed executors provided by the ee subsystem 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.

  • The transaction subsystem now supports configuring a maximum timeout for transactions.

  • The undertow subsystem can now be configured to obfuscate the server instance-id data included as part of the request and response JSESSION_ID cookie.

  • 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 (embedded cache)

    • org.infinispan.client.hotrod (client for remote infinispan server)

    • org.infinispan.commons

  • 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 legacy-compliant-principal-propagation to application-security-domain component in the ejb3 subsystem. This attribute is optional and the principal propagation is legacy compliant by default.

WildFly Preview

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-core, wildfly-servlet, wildfly-ee, wildfly and 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 or wildfly-ee you 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 or wildfly-ee feature 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-pack feature 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-core and wildfly-servlet feature packs for those who wish to use them, although they may be discontinued at some point.

Standards Support

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.

JDK Support

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.

Documentation

The WildFly 23 documentation is available at the docs.wildfly.org site. The WildFly 23 management API documentation is in the wildscribe section of the WildFly 23 docs.

Jira Release Notes

The full list of issues resolved is available in the WFLY JIRA project. Issues resolved in the WildFly Core 15 release included with WildFly 23 are available in the WFCORE JIRA project.

Enjoy!

Thank you for your continued support of WildFly. We’d love to hear your feedback at the WildFly forum.

WildFly is fully open. All components are open source and follow a community-focused development process.

This website was built with Jekyll is hosted on Github Pages and is completely open source. If you want to make it better, fork it and show us what you’ve got.

Navigation
Contribute
Get Help
Find more Red Hat Middleware Community Projects
CC by 3.0 | Privacy Policy Sponsored by