Jakarta EE 10 Platform and MicroProfile 6 in Open Liberty 22.0.0.13-beta

In the Open Liberty 22.0.0.9-beta, we made available Jakarta EE 10 Core Profile and ever since we’ve been hard at work releasing more Jakarta EE 10 features with each subsequent beta. We’re proud to announce that the 22.0.0.13-beta is the culmination of that effort and makes available Jakarta EE 10.0 Application Client, Jakarta EE Web Profile 10.0, and Jakarta EE Platform 10.0.

Liberty provides convenience features for running all of the component specifications that are contained in the Jakarta EE Web Profile and Jakarta EE Platform. The webProfile-10.0 and jakartaee-10.0 Liberty features provide the Jakarta EE Web Profile and Jakarta EE Platform version 10 Liberty features respectively. For Jakarta EE 10 features in the application client, use the jakartaeeClient-10.0 Liberty feature.

Using these convenience features enables developers to rapidly develop applications using all of the APIs contained in the Web Profile and Platform specifications. Unlike the webProfile-9.1 Liberty feature, the webProfile-10 Liberty feature does not enable the XML Binding feature, because XML Binding is not a Web Profile component specification. If your application relies on XML Binding APIs, you must explicitly enable the xmlBinding-4.0 Liberty feature when using the webProfile-10.0 Liberty feature.

To enable the Jakarta EE 10 beta features in your application’s server.xml:

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 10 Web Profile beta features at once:

To run Jakarta EE 10 features on the Application Client Container in your application’s client.xml:

For more information see the Jakarta EE Platform 10 Specification and the Jakarta EE Web Profile 10 Specification.

Jakarta Authentication defines a general low-level SPI for authentication mechanisms, which are controllers that interact with a caller and a container’s environment to obtain and validate the caller’s credentials and pass an authenticated identity (such as name and groups) to the container.

Multiple enhancements are made available in Jakarta Authentication 3.0, including methods to add and remove a single server auth module, and the addition of default methods to ServerAuth and ClientAuth modules.

You can enable the Jakarta Authentication 3.0 feature by enabling the appAuthentication-3.0 feature in the server.xml file:

For more information, see the Jakarta Authentication 3.0 specification.

Jakarta Authorization defines a low-level SPI for authorization modules, which are repositories of permissions facilitating subject based security by determining whether a given subject has a given permission, and algorithms to transform security constraints for specific containers (such as Jakarta Servlet or Jakarta Enterprise Beans) into these permissions.

The Jakarta Authorization 2.1 specification provides enhancements to the Jakarta Authorization 2.0 specification by the addition of new methods to read permissions. One such addition is the ability to get the PolicyConfiguration, which is used for authorization. Prior to Jakarta Authorization 2.1, the spec did not have the flexibility to read permissions from the PolicyConfiguration and required complex wrapper code to get the PolicyConfiguration.

You can enable the Jakarta Authorization 2.1 feature by using the appAuthorization-2.1 feature in the server.xml file:

For more information see the Jakarta Authorization 2.1 specification.

Application Security 5.0 enables support for securing the server runtime environment and applications using Jakarta Security 3.0. The Jakarta Security 3.0 specification allows using built-in authentication mechanisms and identity stores as well as providing your own custom implementations for authenticating users to protected resources. The specification introduces a new built-in authentication mechanism based on the Authorization Code Flow of the OpenID Connect Core 1.0 specification.

Jakarta Security 3.0 allows using the new @OpenIdAuthenticationMechanismDefinition annotation to configure a built-in OpenID Connect authentication mechanism to function as an OpenID Connect client, or Relying Party (RP), so that you can use an OpenID Connect Provider (OP) as a single sign-on identity provider. It also introduces the OpenIdContext bean and various APIs for handling the access token, identity token, and refresh token.

You can use the @OpenIdAuthenticationMechanismDefinition annotation in a Web or JAX-RS application to enable an OpenID Connect client for that application. The following example shows a servlet with a minimal @OpenIdAuthenticationMechanismDefinition annotation when the OP is a Liberty OP:

You can enable the Application Security 5.0 (Jakarta Security 3.0) feature by using the appSecurity-5.0 feature in the server.xml file:

For more information about the @OpenIdAuthenticationMechanismDefinition annotation and its attributes, refer to the 2.4.4. OpenID Connect Annotation section of the Jakarta Security 3.0 specification. Please refer to Jakarta Security Module for the documentation of the Jakarta Security 3.0 APIs.

Jakarta Faces is a Model-View-Controller (MVC) framework for building web applications. It offers many convenient features, such as state management and input validation.

Numerous changes have occurred since the last Jakarta Faces release. Notably, Pages (formerly JSP) support has been removed. Managed Beans support has also been removed, and developers should use CDI beans from this version forward. The namespaces also have been updated from http://xmlns.jcp.org/jsf/* to jakarta.faces.*. Otherwise, new attributes have been added to existing tags: multiple and accept for h:inputFile and onerror for f:websocket. Developers can now create facelets programmatically rather than building them via XML. Extensionless mapping is implemented, so URLs no longer need to include /faces or .xhtml mappings. Two new tags have been added to create a nested collections (i.e., optgroup containing option elements): f:selectItemGroups and f:selectItemGroup. These are just some significant changes, but there are many more.

The faces-4.0 feature uses MyFaces, but if you want to use an alternative Faces implementation, such as Mojarra 4.0, you can use the facesContainer-4.0 feature instead. The Faces API and implementation jars just need to be included in the application WEB-INF/lib folder.

You can enable the Jakarta Faces 4.0 feature by using the faces-4.0 feature in the server.xml file:

To enable the Jakarta Faces 4.0 feature, add faces-4.0 to the server.xml file:

You can find more information regarding the many changes in Faces 4.0 in the What’s new in Faces 4.0? article. The Javadoc, specification documentation, and other information can be found on the Faces 4.0 page.

MicroProfile 6.0 enables applications to use MicroProfile APIs together with Jakarta EE 10 Core Profile. The complete list of MicroProfile 6.0 specifications includes:

The following specifications in MicroProfile 6.0 release are either new or have some major or minor update when compared to MicroProfile 5.0:

MicroProfile 6.0 has the following backward incompatible changes compared to MicroProfile 5.0:

It’s also worth noting that MicroProfile Metrics 5.0 has incompatible changes compared to MicroProfile Metrics 4.0.

You can enable the MicroProfile 6 feature by using the microProfile-6.0 feature in the server.xml file:

To find out more, take a look at the MicroProfile 6.0 Release.

Open Liberty provides First Failure Data Capture(FFDC) capability which instantly collects information about events and conditions that might lead up to a failure. In certain scenarios, the number of files in the FFDC directory can grow to a very large amount. Currently, Open Liberty automatically purges FFDC files in excess of 500 and this value is not configurable. This beta release introduces new functionality which automatically purges FFDC log files after they reach a configured age. This is done through a new configuration attribute, maxFfdcAge.

maxFfdcAge is the maximum desired age before an FFDC file is deleted. At midnight everyday, any FFDC file that has reached the maximum configured age will be deleted. Specify a positive integer followed by a unit of time, which can be days (d), hours (h), or minutes (m). For example, specify 2 days as 2d. You can include multiple values in a single entry. For example, 2d6h is equivalent to 2 days and 6 hours.

Example server.xml configuration:

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.