More Jakarta EE 10 and MicroProfile 6 features make their debut in Open Liberty 22.0.0.12-beta!

Jakarta Pages is a template engine that allows developers to mix various content, such as HTML, XML, and Java code, and translate it into a Jakarta Servlet. Jakarta Standard Tag Library allows for tags to encapsulate common functionality used in many web applications. The Open Liberty pages-3.1 feature is an implementation of both the Jakarta Pages 3.1 and Jakarta Standard Tag Library 3.0 specifications. It includes new features, behavior clarifications, and deprecations from the previous 3.0 version.

The new pages-3.1 feature allows developers to identify undefined Expression Language variables by using a new option, which raises a PropertyNotFoundException and can be set in one of two ways. The errorOnELNotFound attribute is set as a page or tag directive. The <error-on-el-not-found> element is set in the web.xml file.

Previously, imported packages and classes were only available to the scripting environment (i.e. scriptlet tags). However, with version 3.1, they are also available in the Expression Language environment within the page. Default imports (such as jakarta.servlet, jakarta.servlet.jsp, jakarta.servlet.jsp.http) are consistent between both environments. Related changes included internal refactoring of the ScopedAttributeELResolver to create ImportELResolver and the addition of the NotFoundELResolver, which always resolves the requested value and returns null.

Other significant changes include the deprecation of the isThreadSafe directive, the jsp:plugin (including the related jsp:params and jsp:fallback) actions, and any methods which overrode ELResolver.getFeatureDescriptors().

As for Jakarta Tags 3.0, the largest change includes the Tag URI renaming when referencing tag libraries. For example, jakarta.tags.core now replaces the http://xmlns.jcp.org/jsp/jstl/core URI when importing the core tag library. However, the implementation kept older URIs for backwards compatibility. The remaining changes related to general clean up of the documentation.

To enable the new Jakarta Server Pages 3.1 and Jakarta Standard Tag Library 3.0 features, add the pages-3.1 feature to your server.xml:

For more information about Jakarta Server Pages and Jakarta Standard Tag Library, refer to the following links:

Jakarta WebSocket allows communication via the WebSocket protocol, allowing for full-duplex communication between endpoints. This means that a single, persisted connection is made across the endpoints, allowing both the server and client to continuously and simultaneously push information to each other.

Jakarta WebSocket 2.1 is the latest version of the specification and provides several new features and behavior clarifications aimed at improving WebSocket development. Firstly, when setting up dependencies, developers are likely to notice the API JARs are refactored into client and server JARs. However, both APIs are available as part of the websocket-2.1 feature.

HTTP connection upgrades to the WebSocket protocol can now occur via the ServerContainer.upgradeHttpToWebSocket() method​ rather than IBM’s specific WsWsocServerContainer.doUpgrade() method.

Another change regards the Session#getUserProperties() method. The returned map is now a copy per endpoint instance, per WebSocket session. Additionally, the server session’s user properties are initially populated by the ServerEndpointConfig.getUserProperties() method, so endpoints can retrieve properties set in the ServerEndpointConfig.Configurator.modifyHandshake() method​. This is similar to the client session as the user properties are a shallow copy from the EndpointConfig.getUserProperties() method.

Lastly, there were many clarifications in the spec, such as requiring the Session.getRequestURI() method to return the whole URI. These clarifications can be viewed on the Jakarta WebSocket 2.1 page.

You can enable the Jakarta WebSocket 2.1 feature by using the websocket-2.1 feature in the server.xml file,

For more information about Jakarta WebSocket, refer to the following links:

The updates in Jakarta Batch 2.1 primarily focus on improved integration with Context Dependency Injection (CDI). Discovery of Batch artifacts is now standardized via CDI, whereas before it was not fully defined in the specification.

Previously, the default JobOperator was only made available from a static factory method, BatchRuntime.getJobOperator(). With Jakarta Batch 2.1, the default JobOperator is provided as a CDI bean unless one is defined by the user application, if an injectable field is available as defined by:

Previously, the @BatchProperty annotation allowed for injection of String-type values only, but is now expanded to most other primitive types. For example:

This property can have other types in Jakarta Batch 2.1, including Boolean, Integer, Long, Float, and Double. For example:

The batch-2.1 feature is the implementation of Jakarta Batch 2.1 for use with other Jakarta EE 10 features. It can be activated by including the batch-2.1 feature directly, or by including batchManagement-1.0 along with another Jakarta EE 10 feature. For example:

For more information regarding Jakarta Batch 2.1, refer to the following links:

Jakarta Messaging is a set of APIs to standardize message communication between applications, defining how the messages are created, sent, received, and interpreted. Jakarta Messaging 3.1 provides minor changes and enhancements to the specification. Two noteworthy updates are the requirement for Java 11 and making the @JMSConnectionFactoryDefinition and @JMSDestinationDefinition annotations repeatable.

To enable the new Jakarta Messaging 3.1 feature, add the messaging-3.1 feature to your server.xml:

For more information about Jakarta Messaging, refer to the following links:

Jakarta XML Web Services 4.0 is a set of APIs that allows applications to deploy SOAP-based web services on the Jakarta EE 10 platform. This set of APIs includes both the XML Web Services 4.0 specification, which now incorporates the Jakarta Web Services Metadata specification, as well as the Jakarta SOAP with Attachments 3.0 specification.

Although the changes introduced in XML Web Services 4.0 are relatively minor, they do include the requirement for Java SE 11, as well as incorporating the Jakarta Web Services Metadata specification into XML Web Services 4.0.

To enable the new Jakarta XML Web Services 4.0 feature, add the xmlWS-4.0 feature to your server.xml:

For more information about Jakarta XML Web Services, refer to the following links:

The MicroProfile JSON Web Token 2.1 specification allows the use of a JWT to authenticate and authorize requests to a service. The specification simplifies managing the validation of the JWT by introducing three new MicroProfile Config properties, along with corresponding mpJwt attributes.

The MicroProfile Metrics 5.0 feature is the implementation of the Eclipse MicroProfile Metrics 5.0 release and is compatible to run only with other Jakarta EE 10 features. This latest version of MicroProfile Metrics includes both new functionality and significant changes to the functionality in MicroProfile Metrics 4.0 (i.e. the Open Liberty mpMetrics-4.0 feature).

Before we cover the new, lets first quickly go over the changes to existing functionality. Most notable is the removal of the Meter, ConcurrentGauge and SimpleTimer metrics. A consequence of this change is that the REST.request metric, which was previously backed by a SimpleTimer metric, is now a Timer metric. For the publishing of metrics, only the Prometheus format is now available, and the JSON formatted output has been removed. Additionally, the metrics endpoint for a specific metric registry scope and metric is no longer accessed through a tree hierarchy, but rather through query params. For example, /metrics/base/jvm.uptime is accessed through /metrics?scope=base&metric=jvm.uptime. The /metrics?scope=base endpoint by itself retrieves the metrics for the base metric registry.

New in this release is the introduction of user-defined custom scopes. Prior to this release, there was only the base, vendor and application scopes and only the application scope could be used to register metrics. Now, metrics can be registered to a user-defined metric registry scope in one of the following two ways.

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.