back to all blogsSee all blog posts

Notable bug fixes in 25.0.0.11

image of author
Navaneeth S Nair on Nov 4, 2025
announcements , release ,
Post available in languages:

This GA release includes significant bug fixes that enhance stability, improve performance, and provide a smoother user experience.

Check out previous Open Liberty GA release blog posts.

Develop and run your apps using 25.0.0.11

If you’re using Maven, include the following in your pom.xml file:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.11.5</version>
</plugin>

Or for Gradle, include the following in your build.gradle file:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.9.5'
    }
}
apply plugin: 'liberty'

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging and application management all from within your IDE.

Ask a question on Stack Overflow

Notable bugs fixed in this release

Several bugs have been fixed in this release. The following sections highlight some of the key issues that were resolved. For a complete list of fixes, see the full list of bugs fixed in 25.0.0.11.

  • appsWriteJSON not working correctly when JSON record ends with new line.

    When using the Logback logging framework and the logger is configured to route the logging events to STDOUT with an encoder that converts the message to JSON format (e.g., co.elastic.logging.logback.EcsEncoder), the message overall will end with a new line.

    Combined with a OpenLiberty server where the appsWriteJson configuration is set to true, the expected behavior is that the emitted JSON from Logback would not be wrapped within the message value of the typical Open Liberty JSON log output. However, this is the case.

  • Fix the exception in multipart data asynchronous call

    Sending multipart/form-data with MicorProfileRestClient asynchronous results in below exception.

    java.util.concurrent.CompletionException: jakarta.ws.rs.ProcessingException: RESTEASY004655: Unable to invoke request: jakarta.ws.rs.WebApplicationException: Unexpected entity instance: org.jboss.resteasy.plugins.providers.multipart.ResteasyEntityPartBuilder$EntityPartImpl

  • AutoDecompress is not working correctly.

    POST request, with compressed body, results in:

    SRVE0216E: post body contains less bytes than specified by content-length exception.

  • Design Issue: Inconsistent behaviour for server create with server names containing non-alphanumeric characters

    When creating a server using ./server create …​ if the server name contains non-alphanumeric characters (those not specified in documentation) the behaviour is inconsistent.

    For example:

    ./server create 'this£server'

    returns:

    CWWKE0005E: The runtime environment could not be launched.
CWWKE0012E: The specified server name contains a character that is not valid (name=this£server). Valid characters are: Unicode alphanumeric (e.g. 0-9, a-z, A-Z), underscore (_), dash (-), plus (+), and period (.). A server name cannot begin with a dash (-) or period (.).

    but

    ./server create 'this$server'

    returns:

    Server this created.

    Also, when a server name contains whitespaces, whether the server name is provided inside quotes or not a server is created using the text before the first whitespace. For example:

    ./server create 'this server'

    returns:

    CWWKE0027W: Only one server may be specified on the command line; subsequent names will be ignored (server=this, ignored=server).
Server this created.

  • Support continued authentication when custom Subject is not in cache

    In a Single Sign-On (SSO) environment, users occasionally need to temporarily elevate their privileges to administrator level within an application to perform specific administrative tasks. However, an AuthenticationException prevents this scenario from functioning properly.

    The issue occurs despite the LTPA (Lightweight Third-Party Authentication) token being valid- it can be successfully decrypted and parsed, with both its expiration date and signature properly verified.

    The authentication failure happens specifically because the WebSphere Liberty server cannot locate the elevated user’s Subject in its authentication cache, resulting in authentication failure during the privilege elevation process.

    This limitation prevents legitimate administrative operations in scenarios where temporary privilege elevation is required within the same SSO session.

Get Open Liberty 25.0.0.11 now

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