Open Liberty 22.0.0.5提供了对配置多个SSL协议的支持，允许用户创建一个小的、自定义的协议集，服务器可以用于SSL/TLS连接。在这个版本中还有一个用于ws-schemagen.jar的新schemaGen包装器，以及几个重要的bug修复。
在Open Liberty22.0.0.5中：
查看22.0.0.5中修复的bug列表。
使用22.0.0.5运行你的应用程序
如果你使用Maven，这里有坐标：
<dependency>
<groupId>io.openliberty</groupId>
<artifactId>openliberty-runtime</artifactId>
<version>22.0.0.5</version>
<type>zip</type>
</dependency>
或者使用Gradle：
dependencies {
libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[22.0.0.5,)'
}
或者如果你使用的是Docker：
FROM open-liberty
或者看一下我们的下载页面。
对配置多个SSL协议的自由度支持
该功能引入了在SSL/TLS 配置的sslProtocol 属性上配置多个特定的SSL/TLS 协议值的能力。
在这个版本之前，只能为sslProtocol 属性指定一个单一的值，它要么设置一个单一的协议，如TLSv1 ，要么设置用户不可更改的多个协议，如TLS ，它在IBMJSSE2中启用TLS v1.0, v1.1和v1.2协议。 从这个版本开始，用户可以指定一个他们想启用的特定协议的列表，允许他们创建小的、自定义的协议集，服务器可以为SSL/TLS 连接使用。 一个可能的使用情况是将该值设置为两个密码学上最强的协议：TLSv1.2 和TLSv1.3 。 请注意，启用多个协议的值，如TLS ，不能被包括在列表中。
要配置一个逗号分隔的协议值列表，可以在SSL 配置中的sslProtocol 属性上设置：
<ssl id="defaultSSLConfig" keyStore="defaultKeyStore" sslProtocol="TLSv1.3,TLSv1.2"
通过这种配置，入站连接将只接受来自使用TLSv1.3 或TLSv1.2 的客户端的连接。出站连接也将被限制在这两个协议中。
将该功能添加到server.xml ：
<server>
<featureManager>
<feature>transportSecurity-1.0</feature>
</featureManager>
</server>
ws-schemagen.jar的新schemaGen包装器
现有的ws-schemagen.jar 工具，在wlp/bin/tools 目录中，用于为Liberty安装和其他已安装的产品扩展生成模式。
在22.0.0.5之前，运行该工具的方法是使用以下语法：
java [JVM options] -jar ws-schemagen.jar [options] outputFile
在这个版本中，一个schemaGen 脚本被添加到wlp/bin/tools 目录中。这只是一个执行JAR 的包装脚本，使语法变得更加简单：
./schemaGen [options] outputFile
欲了解更多信息，请参考schemaGen命令文档。
此版本中修复的显著错误
我们花了一些时间来修复错误。下面的部分描述了在这个版本中解决的一些问题。如果你有兴趣，这里是22.0.0.5中修复的全部bug列表。
-
JaxRS-客户端在使用Java17执行PATCH-requests时失败
以前，当通过
HTTPS执行PATCH请求时，CXF无法执行该请求。它退回到POST。用户会收到类似以下的堆栈跟踪。14/04/2022, 13:55:52:682 CEST] 0000003b f.rt.transports.http.3.2:1.0.63.cl220420220328-1303(id=151)] W java.lang.reflect.InaccessibleObjectException: Unable to make field private final sun.net.www.protocol.https.DelegateHttpsURLConnection sun.net.www.protocol.https.HttpsURLConnectionImpl.delegate accessible: module java.base does not "opens sun.net.www.protocol.https" to unnamed module @51bce45d at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178) ...我们现在已经更新了java9.options以正确处理JAXRS PATCH请求。
-
与OL 22.0.0.3打包的SpringBoot应用程序无法运行
当使用OL 22.0.0.3将SpringBoot应用程序打包成jar文件时，用户会遇到以下异常。
: Started Application in 2.764 seconds (JVM running for 6.19) 2022-04-01 16:51:29.686 INFO 64794 --- [ecutor-thread-9] ConditionEvaluationReportLoggingListener : Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled. 2022-04-01 16:51:29.726 ERROR 64794 --- [ecutor-thread-9] o.s.boot.SpringApplication : Application run failed javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com.ibm.ws.kernel.boot.jmx.internal.PlatformMBeanServerBuilder: java.lang.ClassNotFoundException: com.ibm.ws.kernel.boot.jmx.internal.PlatformMBeanServerBuilder at java.management/javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:502) ~[na:na] at java.management/javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:535) ~[na:na] at java.management/javax.management.MBeanServerFactory.newMBeanServer(MB我们现在已经解决了这个问题，用户应该不会再遇到这种异常。
-
以前，关闭一个已经超时的安全WebSocket连接可能会导致WebContainer线程挂起，如下所示：
ThreadMonitor W WSVR0605W: Thread "WebContainer : 1" (0000020d) has been active for 17823 milliseconds and may be hung. There is/are 1 thread(s) in total in the server that may be hung. at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:189) at com.ibm.ws.wsoc.WsocConnLink.finishReadBeforeClose(WsocConnL ink.java:812) at com.ibm.ws.wsoc.SessionImpl.close(SessionImpl.java:394) at com.ibm.ws.wsoc.EndpointManager.httpSessionExpired(EndpointM anager.java:166) ...我们现在已经修复了这个问题，这意味着WebSocket应关闭连接，WebContainer线程应按预期退出。
-
当一个
JSP包含了另一个JSP，而这个jar包含在WEB-INF/lib下，过时的依赖性检查表现出两个问题，取决于jsp-attributetrackDependencies的值。当trackDependencies是true（默认）时，日期检查会失败，导致JSP在每次调用时都要重新编译。这就出现了重复信息的症状：SRVE0242I: [ ... ] Initialization successful. SRVE0253I: [ ... ] Destroy successful.当
trackDependencies为false，可能会出现如下的NullPointerException：java.lang.NullPointerException at com.ibm.ws.jsp.webcontainerext.AbstractJSPExtensionServletWrapper.isDependentOutdated(AbstractJSPExtensionServletWrapper.java:735) at com.ibm.ws.jsp.webcontainerext.AbstractJSPExtensionServletWrapper._checkForTranslation(AbstractJSPExtensionServletWrapper.java:416) at com.ibm.ws.jsp.webcontainerext.AbstractJSPExtensionServletWrapper.checkForTranslation(AbstractJSPExtensionServletWrapper.java:253) at com.ibm.ws.jsp.webcontainerext.AbstractJSPExtensionServletWrapper.handleRequest(AbstractJSPExtensionServletWrapper.java:163) ....现在，
JSP`s should not recompile on each call unless there is a valid update of an included file, and users should no longer experience `NullPointerExceptions。这个问题是由于当trackDependencies是false时，未能初始化一个dependentsList。 -
Open Liberty中的Netty组件是2021年12月发布的版本
4.1.72.Final。最新的版本4.1.75.Final，包含了各种错误修复和对当前版本的改进。我们拉入了最新的Netty版本(4.1.75)，以确保Open Liberty与上游的修复和改进保持同步。 -
FeatureUtility isf不能解决已经安装的用户功能
自Open Liberty 22.0.0.3以来，
featureUtilityinstallServerFeature命令未能定位用户特征，当该特征被安装到WLP_USER_DIR。我们应该期望该特征被安装，或者通知用户该特征已经被安装。我们发现WLP_USER_DIR被覆盖了，这在试图找到已经安装到WLP_USER_DIR的功能时造成了问题。这个问题现在已经解决了。 -
当
/metrics端点被击中并且SimpleTimer度量被格式化时，有两个明确的调用来检索SimpleTimer的值（最小时间持续时间或最大时间持续时间）。以前，这两次调用可能是在一整分钟完成之前和之后进行的。这可能导致NullPointerException，如果SimpleTimer，作为完成整分钟的一部分，删除该值（即在之前的整分钟没有记录任何值来更新最小/最大值）。SRVE0777E: Exception thrown by application class 'io.openliberty.microprofile.metrics30.internal.helper.PrometheusBuilder30.buildSimpleTimer30:111' java.lang.NullPointerException at io.openliberty.microprofile.metrics30.internal.helper.PrometheusBuilder30.buildSimpleTimer30(PrometheusBuilder30.java:111) at io.openliberty.microprofile.metrics30.internal.writer.PrometheusMetricWriter30.writeMetricMapAsPrometheus(PrometheusMetricWriter30.java:101) at io.openliberty.microprofile.metrics30.internal.writer.PrometheusMetricWriter30.writeMetricsAsPrometheus(PrometheusMetricWriter30.java:47) at com.ibm.ws.microprofile.metrics.writer.PrometheusMetricWriter.write(PrometheusMetricWriter.java:83) at com.ibm.ws.microprofile.metrics.BaseMetricsHandler.handleRequest(BaseMetricsHandler.java:83)我们已经修补了这个问题，确保
PrometheusBuilder不单独检索SimpleTimer最大/最小值，而是在格式化时使用一个保存的值。这意味着用户不再遇到这种NullPointerException。
