MicroProfile 6 and Jakarta EE 10 guide updates in Open Liberty 23.0.0.5

Michal Broz on May 30, 2023

announcements , microprofile , release , jakarta-ee ,

Post available in languages: 日本語 ,

Concurrent with the Open Liberty 23.0.0.5 release, 44 of the Open Liberty guides have been updated to make use of the latest MicroProfile 6 and Jakarta EE 10 specifications. Various bugs have been fixed as part of this release.

In Open Liberty 23.0.0.5:

44 guides updated to use MicroProfile 6 and Jakarta EE 10
Notable bug fixes

Check out previous Open Liberty GA release blog posts.

Run your apps using 23.0.0.5

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>23.0.0.5</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[23.0.0.5,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page.

44 guides updated to use MicroProfile 6 and Jakarta EE 10

As Open Liberty features and functionality continue to grow, we continue to add new guides to openliberty.io on those topics to make their adoption as easy as possible. Existing guides also receive updates to address any reported bugs/issues, keep their content current, and expand what their topic covers.

Concurrent with the 23.0.0.5 release, the following 44 guides have been updated to use the latest MicroProfile 6 and Jakarta EE 10 specifications:

For the full list of Open Liberty guides, refer to the guides page.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 23.0.0.5.

Memory Leak in MicroProfile OpenAPI’s SchemaRegistry.current

A user reported a memory leak that occurred with each application restart, where 100MB of additional memory was used each time. The culprit ended up coming from MicroProfile OpenAPI’s SchemaRegistry class.

This issue has been reported upstream to SmallRye, and has also been fixed directly in Liberty.
HTTP/2 max frame size exceeded when compression is used

When compression is configured in the server.xml on an httpendpoint and http/2 is used, the http/2 max frame size may be exceeded, leading to a FRAME_SIZE_ERROR appearing in the server’s log.

This issue has been resolved and the http/2 response data is now split into multiple data frames to avoid sending a data frame larger than the http/2 max frame size of the client.

EntryNotFoundException thrown in federated registries when using custom input/output configuration

When running with federatedRegistries-1.0, it is possible to get an EntryNotFoundException when defining a non-identifier type property for the federated registries input/output mapping. This exception can occur in any of the com.ibm.ws.security.wim.registry.util.*Bridge classes, but the key is it originates from a BridgeUtils.getEntityByIdentifier call.

The following is an example stack:

com.ibm.websphere.security.EntryNotFoundException: CWIML1010E: The user registry operation could not be completed. The uniqueId = null and uniqueName = null attributes of the identifier object are either not valid or not defined in the back-end repository.
        at com.ibm.ws.security.registry.internal.UserRegistryWrapper.getGroupsForUser(UserRegistryWrapper.java:248)
        at web.UserRegistryServlet.handleMethodRequest(UserRegistryServlet.java:140)
        at web.UserRegistryServlet.doGet(UserRegistryServlet.java:174)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1258)
        ...

This issue has been resolved and the method no longer throws EntryNotFoundException.

requestTiming-1.0 causes elevated (or spiking) CPU performance due to the SlowRequestManager

When using the requestTiming-1.0 feature in OpenLiberty, the CPU usage is elevated. CPU impact correlates to CPU capacity.

This is more obvious when a lower threshold is set for the "slow request" threshold (i.e. e.g. <= 15s). Even so, may not encounter a noticeable impact depending on CPU capacity.

This is also more obvious if the request has a high hung threshold or if the request is hung indefinitely and can not be terminated by by the interruptHungRequest attribute (leading to an indefinite hang). This allows for a bigger window of opportunity to witness any CPU spikes/elevation.

This issue has been resolved and the elevated CPU usage no longer occurs.
Request Timing metrics not showing up with mpMetrics-5.0 (when used with requestTiming-1.0 feature).

When using the mpMetrics-5.0 and requestTiming-1.0 features, the request timing metrics are not being provided.

This issue has been resolved and the expected request timing metrics are now provided.

Get Open Liberty 23.0.0.5 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

See all blog posts