Use the Password Utilities feature without forcefully federating stand alone user registries in Open Liberty 22.0.0.9
Open Liberty 22.0.0.9 has arrived and brings the Password Utilities 1.1 feature, which does not forcefully federate stand-alone user registries. Along with the new feature, this release also includes several notable bug fixes.
In Open Liberty 22.0.0.9:
Run your apps using 22.0.0.9
If you’re using Maven, here are the coordinates:
<dependency>
<groupId>io.openliberty</groupId>
<artifactId>openliberty-runtime</artifactId>
<version>22.0.0.9</version>
<type>zip</type>
</dependency>
Or for Gradle:
dependencies {
libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[22.0.0.9,]'
}
Or if you’re using Docker:
FROM open-liberty
Or take a look at our Downloads page.
Stand-alone user registries no longer forcefully federated (Password Utilities 1.1)
A new version of the Password Utilities feature, passwordUtilities-1.1, is available. This version of the feature does not start the Federated User Registry feature or the Jakarta Connectors feature. When you use this version of the feature, stand-alone user registries are not forcefully federated, which sometimes results in slightly different behavior than the previous version. The previous feature version, passwordUtilities-1.0, starts the Federated User Registry and Jakarta Connectors features by default.
To enable Password Utilities 1.1, add the passwordUtilities-1.1
feature to the list of features in your server.xml file:
<featureManager>
<feature>passwordUtilities-1.1</feature>
</featureManager>
For more information about the Password Utilities feature, check out the feature documentation.
Security vulnerability (CVE) fixes in this release
There are no security vulnerability fixes for this release. 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 22.0.0.9.
-
Invalid character warning for colon in WorkQueueManagerImplMBeanWrapper objectName
A colon character (
:
) in the Apache CXF WorkQueueManagerImplMBeanWrapper class’s objectName creates a warning and ajavax.management.MalformedObjectNameException
caused by the invalid:
character whenjavax.management.ObjectName.construct
is called. This issue occurs in Open Liberty 22.0.0.8, though it did not appear in 22.0.0.7.A fix to this issue was made where by the removal of an invalid
:
character from URI base in the bus ID and resulted in no additional warning messages. More information can be found in #22069 -
CXF property cxf.ignore.unsupported.policy is not processed correctly in Liberty 22.0.0.8
In Liberty 22.0.0.8, when the JVM system property
cxf.ignore.unsupported.policy
is set to true, some unsupported policy assertions in the WSDL file are not ignored as expected.This has since been resolved to now process the
cxf.ignore.unsupported.policy
correctly. -
Expiration fields are not compared in an LTPA Token
When two expiration times are present in an LTPA token, the times must be compared to confirm whether they are within an acceptable difference.
The issue is fixed via #21883 and Open Liberty will now reject LTPA tokens when the two expiration times in the token are not within an acceptable difference by throwing an invalidTokenException.
-
Starting with OSGi R7 Core specification, bundles are allowed to import (using
Import-Package
header) packages fromjava.
(e.g.java.io
). When installing a Liberty feature that includes a bundle that imports ajava.
package, the bundle fails to resolve because Liberty does not configure the OSGi framework (Equinox in this case) to export thejava.*
packages available in the running JVM.The issue is resolved via #16188 and Open Liberty will now configure the OSGi framework to export the available java.* packages for the running JVM.
-
MP Fault Tolerance 1.x can log an FFDC when a method times out at the same time as it completes
When a method times out at the same time as it completes, an FFDC may be logged. Aside from the FFDC being logged, there are no other symptoms.
There has been a fix to timeout cancellation race condition which resolves:
A lock shared between
stop()
andtimeout()
, but if the timeout has fired, the timeout future is not complete at the point wheretimeout()
releases the lock. This givesstop()
a chance to run and attempt to cancel the future. Doing this results in anInterruptedException
which causes and FFDC to be emitted by the policy executor.By checking the value of timeout, it avoids trying to cancel the timeout task if the timeout has already fired and interrupted our thread. There has also been a package added to the FT trace group.
Both the fix to the timeout cancellation race condition and adding the package to trace group has resolved the issue of MP Fault Tolerance 1.x.
-
OpenAPI 2.0+ throws error at startup
After enabling mpOpenApi-2.0 or mpOpenApi-3.0. at startup, this error might occur because the MP OpenAPI implementation tries to get a MicroProfile Config object before the MicroProfile Config feature has initialized.
This issue was fixed by only calling
Config.getConfig()
when needed, rather than when the component starts to avoid occasional cases where the config component hasn’t initialized yet. The fixes are in #21881 -
Multiple protocols not always getting honored with the IBMJDK
When the IBM JDK is being used not all protocols in a list of protocols will get honored.
After the fix, each protocol in the list should be able to be used in a connection as long as the protocol is not disabled in the Security configuration.
Get Open Liberty 22.0.0.9 now
Available through Maven, Gradle, Docker, and as a downloadable archive.