back to all blogsSee all blog posts

A number of significant bug fixes in Open Liberty 21.0.0.7

image of author
Jakub Pomykala on Jul 8, 2021
Post available in languages:

Open Liberty 21.0.0.7 comes without any new features but a number of significant bug fixes. A number of new features were released in our Beta version, including MicroProfile 4.1 updates. You can find out more about 21.0.0.8-beta in our beta release blog post.

Run your apps using 21.0.0.7

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

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

Or for Gradle:

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

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

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

  • Occasional login failure of OIDC RP if clientSecret is not configured

    In the OIDC RP, when no clientSecret is configured, validation of the signature of the JWT occasionally would fail with a message similar to:

    CWWKS1739E: A signing key required by signature algorithm [none] was not available. null

    This bug was fixed by updating the JWT validation code in the OpenID Connect client to return a null java.security.Key object as the signature verification key if signatureAlgorithm is set to none in the OpenID Connect client configuration. Before, an HmacKey object was instantiated using the clientSecret value from the OIDC client configuration, even though the Key object will never be used if signatureAlgorithm is set to none. The new behavior avoids a NullPointerException when a clientSecret is not configured in the OIDC client.

  • EJB Singleton Lifecycle Deadlock

    A Singleton can be locked from the lifecycle event causing a deadlock when:

    • When the Singleton called another managed object (like another session bean or asynchronous bean) OR the Singleton had a lifecycle interceptor.

    • The other managed object calls the Singleton. (Either through an asynchronous method that is invoked at the right time (so a timing problem) or through the method the Singleton called on it).

    For @PreDestroy we are no longer locking the singleton, depending on when the destroy resolves, the other managed object might get an error stating the bean has been stopped/destroyed.
    For @PostConstruct the EJBContainer must lock the creation of SingletonBeans to ensure only one gets created. Instead of deadlocking forever we now have a timeout value of attempting to obtain a lock. This value is 2 minutes by default but configurable by @AccessTimeout value either on the class or the @PostConstruct method. A thread that times out trying to access the Singleton will get a javax.ejb.ConcurrentAccessTimeoutException.

  • Improve featureUtility return code when invalid action name is specified

    Users would see an erroneous return code 0 when an invalid action was specified. This was now changed to return code 20 `. Because of this change any scripted invocations of featureUtility can now detect this.

  • Allow multiple version of singleton feature with featureUtility installFeature command

    FeatureUtility installFeature command did not support the installation of multiple versions of the singleton feature using a single command. As a workaround, users had to install each version of the feature one by one. The fix will now allow users to install multiple versions of the feature in a single command, and will also allow users to install a feature bundle addon (libertyCoreBundle, baseBundle, etc) to install all features that apply to their liberty edition.

  • JavaMail tries to use a resource file that only exists in the implementation

    The javax.mail.Session constructor (from wlp/dev/api/spec/com.ibm.websphere.javaee.mail.1.6_1.0.53.jar) tried to load the resource /META-INF/javamail.default.address.map. However, this file only existed in the implementation (wlp/lib/com.ibm.ws.com.sun.mail.javax.mail.1.6_1.6.53.jar). It is not able to find it, so it caused a warning to show up:

    [WARNING ] expected resource not found: /META-INF/javamail.default.address.map

    This issue was resolved by adding javamail.default.address.map to the app-resource header.

  • concurrencyPolicy loses queue slots when managed executor deactivates and erroneously cancels tasks of other executors

    21.0.0.7 adds the ability for you to make configuration updates that remove managed executors while the server is running, without impacting other managed executors that remain in the server configuration. This is possible even if the managed executors share the same concurrency policy.

  • JSP with trackDependencies should check for updates of included JSP in the extended document root

    JSP with trackDependencies=true does not always check for updates of included JSP in the extended document root. We have now corrected the tests of the Last Modified Date for a dependent JSP file that is in the extended document root.

  • OAuth client registration: Client IDs with GB18030 characters don’t work

    When creating a token containing some GB18030 characters, the token could not be displayed correctly. It also could not be edited nor deleted. This issue was fixed by adding checks to ensure the client_id and client_secret parameters do not contain characters outside of the %x20-7E range, per the OAuth 2.0 spec.

Get Open Liberty 21.0.0.7 now