back to all blogsSee all blog posts

ARM64 container images in Open Liberty 23.0.0.4

image of author
Michal Broz on May 2, 2023
announcements , release , docker ,
Post available in languages: 日本語 ,

Open Liberty 23.0.0.4 provides better, more consistent logging for the features with which the runtime is running. Starting with this release, container images for the ARM64 architecture are available, along with the existing AMD64, PPC64LE, and S390X architectures. This release also includes an important security vulnerability (CVE) fix and many notable bug fixes.

In Open Liberty 23.0.0.4:

Check out previous Open Liberty GA release blog posts.

Run your apps using 23.0.0.4

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

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

Or for Gradle:

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

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

ARM64 container images

Starting with the 23.0.0.3 release, Liberty makes available Red Hat Universal Based Images (UBI) for the ARM64 architecture. That means you can now natively run your Open Liberty based container images on even more platforms, such as Apple’s ARM based silicone (like their M series processors) and Amazon’s AWS Graviton. Prior to these changes, the provided container images were made available for the AMD64, PPC64LE, and S390X architectures.

We recommend using the IBM Container Registry (ICR) as it is not rate limited like Docker Hub.

For more information, reference the Open Liberty container images documentation.

Consistently log features on server start

In previous versions of Liberty, at server start, the feature manager logged a list of added features in a CWWKF0012I audit message and removed features in a CWWKF0013I audit message. In the case of a warm start, the feature manager instead logged the entire list of installed features in the CWWKF0012I message:

[AUDIT ] CWWKF0012I: The server installed the following features: [el-3.0, jsp-2.3, servlet-3.1].

This behavior has lead to confusion from users who expected the CWWKF0012I to always output the full list of enabled features. In the case where the list of features is updated in between server starts, someone might believe that previously enabled features are no longer included.

Starting with 23.0.0.4, Liberty consistently provides the full list of features that are enabled every time the server is started. It also issues messages to identify features that were added or removed since the last start.

Security vulnerability (CVE) fixes in this release

CVE CVSS Score Vulnerability Assessment Versions Affected Notes

CVE-2023-24998

7.5

Denial of service

17.0.0.3 - 23.0.0.3

Affects the servlet-3.0, servlet-3.1, servlet-4.0, servlet-5.0 and servlet-6.0 features

For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

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.4.

  • Insufficient Infinispan cache creation for Liberty httpSessionCache

    We’ve discovered that the way Liberty creates cache instances with Infinispan can cause multiple applications that use the same virtual host name and context-root to share a single Cache instance, even when they’re in entirely separate pods and totally unrelated to each other.

    This behavior causes problems when objects from one app are removed even just by the other app accessing the session. For example:

    [ERROR ] SESN0304E: An exception occurred when reading in an object of the application data for a session from the cache. The exception is: java.lang.ClassNotFoundException: com.ibm.gs.houston.payment.ach.ibm.forms.ACHCreditForm
[ERROR ] SESN0306E: An exception occurred when invalidating a session in the cache. The exception is: java.lang.RuntimeException: Internal Server Error
[ERROR ] SESN0304E: An exception occurred when reading in an object of the application data for a session from the cache. The exception is: java.lang.ClassNotFoundException: com.ibm.gs.houston.payment.ach.ibm.forms.ACHCreditForm

    We resolved this issue by introducing the appInCacheName property, which, when set to true, includes the application name in the corresponding cache.

  • Server hangs at startup when enabling trace specification: com.ibm.ws.*=all

    When the server is started with the com.ibm.ws.*=all trace specification, the server hangs because the application was not loaded yet.

    The issue has been resolved and the server no longer hangs even when a very broad trace level is set.

  • Encrypted value for internalClientSecret within oauthProvider does not work

    The internalClientSecret and internalClientId parameter values within the oauthProvider element configuration of an OpenID Connect Server are used to generate tokens for Personal Token Management and Users Token Management UI pages. However, if the internalClientSecret value is encrypted by the securityUtility command, the two UI pages no longer work. This is caused by an error that states the ClientId and Secret are invalid.

    This issue has been resolved by adding support for encrypting the internalClientSecret value.

  • JSP Options to pick up web-ext jsp-attribute values on start up (honor disableTldSearch to improve app start up time)

    The JSP Engine does not pick up the jsp-attributes during the initial stage of application startup when set by ibm-web-ext.xml or server.xml files. However, later phases of the start up did pick up the jsp-attributes.

    This inadvertently slowed application startup because disableTldSearch (which defaults to true) was not registered when set to false and so the JSP Engine continued its time-consuming search for TLDs in the various application libraries and other locations.

    The issue has been resolved and the JSP Engine now honors the jsp-attributes when they are set by ibm-web-ext.xml or server.xml files.

  • Port MYFACES-4594

    MYFACES-4594 was opened because org.apache.myfaces.LOG_WEB_CONTEXT_PARAMS defaults to dev-only, which is defined in Apache MyFaces Core 4.0 and states the following:

    Indicate if info logging all web config params should be done before initializing the webapp.
With 4.0.0, the default changed from auto to dev-only. where logging no longer occurs in the
production project stage (new default behavior). True enables logging in the production and
development project stages. False disables logging.

    If multiple applications are deployed on a server and not all of them have the ProjectStage set to Development, the context parameters might not work correctly for all the applications. The first application to start would define the logging that would or wouldn’t take place.

    This issue has been resolved and each application is now able to define whether context parameters are logged or not.

  • Java 11 NoSuchAlgorithmException SHA1PRNG when FIPS enabled TS012071744

    When one enables the FIPS feature with the IBM Semeru JDK and the OpenID Connect Client feature, the following FFDC exception is emitted:

    ------Start of DE processing------ = [2/3/23, 18:08:06:748 CET]
Exception = java.security.NoSuchAlgorithmException
Source = com.ibm.ws.security.openidconnect.clients.common.OidcUtil
probeid = 104
Stack Dump = java.security.NoSuchAlgorithmException: SHA1PRNG SecureRandom not available
        at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
        at java.base/java.security.SecureRandom.getInstance(SecureRandom.java:398)
        at com.ibm.ws.security.openidconnect.clients.common.OidcUtil.getRandom(OidcUtil.java:102)
        at com.ibm.ws.security.openidconnect.clients.common.OidcUtil.generateRandom(OidcUtil.java:82)
        at com.ibm.ws.security.openidconnect.client.internal.OidcClientConfigImpl.<clinit>(OidcClientConfigImpl.java:307)
        at com.ibm.ws.security.openidconnect.client.internal.OidcClientWebappConfigImpl.activate(OidcClientWebappConfigImpl.java:47)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    The issue has been resolved and the SHA1PRNG secure random algorithm is used and no FFDC exception occurs.

Get Open Liberty 23.0.0.4 now

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