1.16. 聚合 Quarkus CXF 发行注记 3.15.3 LTS → 3.20.2 LTS

Quarkus TLS registry 是 Quarkus 提供的扩展，可集中 TLS 配置，从而更轻松地在应用程序间管理和维护安全连接。

Quarkus TLS registry 是在 Quarkus CXF 3.16.0+ 中配置信任存储、密钥存储和其他 TLS/SSL 相关设置的新推荐方法：

# Define a TLS configuration with name "hello-tls" 

quarkus.tls.hello-tls.trust-store.p12.path = client-truststore.pkcs12
quarkus.tls.hello-tls.trust-store.p12.password = client-truststore-password

# Basic client settings
quarkus.cxf.client.hello.client-endpoint-url = https://localhost:${quarkus.http.test-ssl-port}/services/hello
quarkus.cxf.client.hello.service-interface = io.quarkiverse.cxf.it.security.policy.HelloService

# Use "hello-tls" defined above for this client
quarkus.cxf.client.hello.tls-configuration-name = hello-tls

Quarkus TLS registry 提供的所有客户端相关选项都支持基于 Vert.x 的 CXF 客户端。

# Deprecated way of setting the client trust store
quarkus.cxf.client.hello.trust-store-type = pkcs12
quarkus.cxf.client.hello.trust-store = client-truststore.pkcs12
quarkus.cxf.client.hello.trust-store-password = client-truststore-password

基于 Vert.x HttpClient 的 HTTP Conduit 是在 Quarkus CXF 3.13.0 中引入的。其用法是可选的，通过在其中一个选项 quarkus.cxf.client."client-name".http-conduit-factory 或 quarkus.cxf.http-conduit-factory 中设置 VertxHttpClientHTTPConduit -factory ：

# Before Quarkus CXF 3.16.0, VertxHttpClientHTTPConduitFactory had to be set explicitly
# Set the HTTPConduitFactory per-client
quarkus.cxf.client."client-name".http-conduit-factory = VertxHttpClientHTTPConduitFactory
# Set the HTTPConduitFactory globally
quarkus.cxf.http-conduit-factory = VertxHttpClientHTTPConduitFactory

从那时起，它进行了一些改进和测试，现在我们现在能够保证它默认。

使用基于 Vert.x HttpClient 的 HTTP Conduit 的主要动机如下：

# A configuration that worked before Quarkus CXF 3.16.0
quarkus.cxf.client.helloAllowAll.client-endpoint-url = https://localhost:8444/services/hello
quarkus.cxf.client.helloAllowAll.service-interface = io.quarkiverse.cxf.it.security.policy.HelloService
quarkus.cxf.client.helloAllowAll.trust-store = client-truststore.pkcs12
quarkus.cxf.client.helloAllowAll.trust-store-password = secret
quarkus.cxf.client.helloAllowAll.hostname-verifier = AllowAllHostnameVerifier

# An equivalent configuration for Quarkus CXF 3.16.0+
quarkus.tls.helloAllowAll.trust-store.p12.path = client-truststore.pkcs12
quarkus.tls.helloAllowAll.trust-store.p12.password = secret
quarkus.tls.helloAllowAll.hostname-verification-algorithm = NONE
quarkus.cxf.client.helloAllowAll.client-endpoint-url = https://localhost:8444/services/hello
quarkus.cxf.client.helloAllowAll.service-interface = io.quarkiverse.cxf.it.security.policy.HelloService
quarkus.cxf.client.helloAllowAll.tls-configuration-name = helloAllowAll

在 Quarkus CXF 3.17.0 之前，基于 VertxHttpClientHTTPConduit 的 CXF 客户端只能同时调用：

@CXFClient("hello")
HelloService hello;

String callHello() {
    // Synchronous CXF client call
    hello.hello("Joe");
}

quarkus CXF 3.17.0 引入了基于 VertxHttpClientHTTPConduit的客户端的异步模式：

import io.smallrye.mutiny.Uni;

@CXFClient("hello")
HelloService hello;

Uni<String> callHelloAsync() {
    return Uni.createFrom()
            // Asynchronous CXF client call returning java.util.concurrent.Future
            .future(hello.helloAsync("Joe"))
            .map(HelloResponse::getReturn);
}

这和现有的 Apache HttpClient 5 Async HTTP 传输非常相似。主要区别在于，您不需要向应用程序添加（现在已弃用的） io.quarkiverse.cxf:quarkus-cxf-rt-transports-http-hc5 依赖项。

您仍然需要使用嵌入式 wsdl2java 工具生成 async 方法。

检查 异步客户端 页面以了解更多信息。

在 Quarkus CXF 3.17.0 之前，基于 VertxHttpClientHTTPConduit的 CXF 客户端没有遵循 HTTP 重定向(HTTP 状态代码 301、302、303 和 307 带有 Location 响应标头)，即使 quarkus.cxf.client."client-name".auto-redirect 已为给定客户端启用了。

Quarkus CXF 3.17.0 添加此功能以及对 quarkus.cxf.client."client-name".max-retransmits 的正确支持。

引入了一个新的配置属性 quarkus.cxf.client."client-name".redirect-relative-uri。它等同于在 CXF 客户端请求上下文上设置 http.redirect.relative.uri 属性，因为 CXF 已支持。

检查 quarkus.cxf.client."client-name".max-same-uri文档以了解更多信息。

特别感谢 @dcheng1248 进行 贡献。

quarkus CXF 3.17.0，增加了对使用 VertxHttpClientHTTPConduit 重定向的支持。它包括请求正文的一些基本内存缓存，用于重新传输。自 Quarkus CXF 3.18.0 起，如果正文的大小超过一些可配置的阈值，则 VertxHttpClientHTTPConduit 能够将数据卸载到磁盘。查看以下新配置选项文档以了解新功能的工作方式：

在 Quarkus CXF 3.20.0 之前，当远程服务响应 需要 401 Unauthorized 或 407 Proxy Authentication required 时，由 VertxHttpClientHTTPConduit 支持的客户端将只是失败，且唯一可能的临时解决方案是使用其他 HTTP conduit，如 URLConnectionHTTPConduit。

自 Quarkus CXF 3.20.0 开始，VertxHttpClientHTTPConduit 通过发送一个从以下一个或多个选项派生的 Authorization 标头值的新请求来正确处理 401 和 407 状态代码：

在 Quarkus CXF 3.19.0 之前，只能通过 quarkus.cxf.client."client-name".tls-configuration-name 或 （现在弃用的） quarkus.cxf.client."client-name".key-store* 和 quarkus.cxf.client."client-name".trust-store* 选项配置信任存储和密钥存储。

如果有多个客户端，此配置可能会获得详细信息。

从 Quarkus CXF 3.19.0 开始，可以使用 quarkus.cxf.client.tls-configuration-name 选项为所有客户端设置信任存储和密钥存储。

在 Quarkus CXF 3.19.0 之前，将 quarkus-jdbc-oracle 与 quarkus-cxf-integration-tracing-opentelemetry 或 quarkus-cxf-rt-ws-rm 合并在单个应用中会导致构建原生镜像时出现错误：

org.graalvm.compiler.debug.GraalError: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException:
Detected a MBean server in the image heap. This is currently not supported, but could be changed in the future.
Management beans are registered in many global caches that would need to be cleared and properly re-built at image build time.
Class of disallowed object: com.sun.jmx.mbeanserver.JmxMBeanServer

我们在 Quarkus CXF 3.19.0 中解决了这个问题。

对于每个服务方法，构建时会生成几个辅助类。它们可能代表某个请求或操作的响应。因此，对于 com.acme.HelloService.hello （） 方法，至少会生成两类 com.acme.jaxws_asm.Hello 和 com.acme.jaxws_asm.HelloResponse。在 Quarkus CXF 3.20.0 和 CXF 4.1.1 之前，不会考虑服务类的名称。因此，当有多个服务接口包含名称相同的方法时，辅助类的名称会冲突。这意味着，只有一组这些类，只有其中一个服务存储在应用程序中。在运行时，应用程序日志中可能会出现以下出错信息：

java.lang.IllegalArgumentException: argument type mismatch
     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
     at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at java.base/java.lang.reflect.Method.invoke(Method.java:568)
     at org.apache.cxf.databinding.AbstractWrapperHelper.createWrapperObject(AbstractWrapperHelper.java:114)
     at org.apache.cxf.jaxws.interceptors.WrapperClassOutInterceptor.handleMessage(WrapperClassOutInterceptor.java:91)
     at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
     at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356)
     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314)
     at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
     at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140)
     at jdk.proxy6/jdk.proxy6.$Proxy132.hello(Unknown Source)

这个问题已在 CXF 4.1.1 和 Quarkus CXF 3.20.0 中解决。现在，考虑服务类的名称。因此，对于上例，生成的类的名称分别为 com.acme.jaxws_asm.helloservice.Hello 和 com.acme.jaxws_asm.helloservice.HelloResponse。

quarkus.cxf.http-conduit-factory 和 quarkus.cxf.client."client-name".http-conduit-factory 的 HttpClientHTTPConduitFactory 值自 Quarkus CXF 2.3.0 中存在。

HttpClientHTTPConduit 从未获得 Quarkus CXF 内的任何实际影响。当 CXF 启动将其用作默认值时，我们会被强制引入自己的默认(URLConnectionHTTPConduitFactory)，以避免诸如 #992,CXF-8885,CXF-8951,CXF-8946,CXF-8903 等错误。现在，我们已有 VertxHttpClientHTTPConduit 在 Quarkus 上支持非常好的情况，因此我们没有其他原因将我们的资源花费在 HttpClientHTTPConduit 上。

HttpClientHTTPConduitFactory 在我们的文档中被标记为弃用，我们在应用程序启动时为 folks 添加了一些警告，以供 folks 使用。

io.quarkiverse.cxf:quarkus-cxf-rt-transports-http-hc5 扩展从 Quarkus CXF 3.19.0 开始已弃用，它被调度在 3.21.0 中删除。改为使用 VertxHttpClientHTTPConduit的异步模式。

这是我们未来仅支持一个基于 Vert.x HttpClient 的单个 HTTP Conduit 工作的一部分。