1

WildFly 32 Beta is released!

 1 week ago
source link: https://www.wildfly.org//news/2024/04/08/WildFly32Beta-released/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Feature Stability Levels

There a number of new features in WildFly 32 Beta1. I’ll wait for the Final release announcement to describe them all; for now I’ll just direct you to the release notes.

Something that’s pretty new in 32 Beta though is that we’ve started to take advantage of the capabilities introduced in WildFly 31 to introduce features at different stability levels. The goal here is to allow users who want to look at features in earlier stages of the development lifecycle to easily do so, without leaving users who are not interested in that in a situation where they may inadvertently use those features.

As noted in the documentation, new features are offered at one of four stability levels: experimental, preview, community and default. Most features in both standard WildFly and WildFly Preview are at default stability, but increasing numbers of new features will be introduced at the other levels, and hopefully will be promoted in later releases up to community or default.

Out of the box, standard WildFly allows use of features at community or default stability, while WildFly Preview allows preview, community or default. If you wish to allow lower stability level features than the out-of-the-box setting, this can be done using the stability command line parameter:

In WildFly 32 Beta we’ve introduced features at all four stability levels. You can identify the stability level of new features by looking at the title of the Jira issue in the release notes. For features at anything other than default stability, the issue title will be prefaced by one of [Experimental], [Preview] or [Community].

Tooling Support for Feature Stability Levels

Our Galleon-based provisioning tooling has also had updates related to feature stability levels: we’ve added configuration options to allow you to control the stability level of features in your installation. This can be used to do things like:

  • Prevent the provisioning of lower stability features, so they are not available for use even when the --stability server start param is used.

  • Enable the inclusion of lower stability features in the configuration files the provisioning tool generates, avoiding the need to use a post-provisioning tool like the WildFly CLI to incorporate them into the configuration.

To limit your installation level to the highest stability features, you would include the following in your maven plugin configuration:

To allow Galleon to include lower stability features in your installation’s generated configuration files, you could do something like:

If one wants to have different values for configuration files and packages (i.e. filesystem resources like JBoss Modules modules), then the <config-stability-level> and <package-stability-level> options are to be used instead of <stability-level>. The use case for using config-stability-level and package-stability-level as an alternative to stability-level is when the user wishes to generate configurations with features at a given stability level while allowing provisioning of packages at a lower level. The presence of the lower stability level packages allows subsequent update of the configuration, e.g. with the WildFly CLI, to enable lower stability features.

The wildfly-maven-plugin 5.0.0.Beta5, wildfly-jar-maven-plugin 11.0.0.Beta2 (for bootable jars) and the Galleon 6.0.0.Beta6 tools all support these stability level configuration options. I encourage you to try them out.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK