Quarkus CXF 3.31.0 and 3.31.1 release notes

These new options control the time duration after which inactive HTTP client connections are closed. Refer to their respective documentation for more details:

Special thanks to @dankristensen for sending the initial pull request.

Since Quarkus CXF 3.31.0, CXF clients can use proxy settings defined via quarkus.proxy.* options.

Refer to the following resources for more details:

Special thanks to Erik Åsén for seeding the idea of global Quarkus Proxy settings by requesting it for all CXF clients.

As mentioned above, since Quarkus CXF 3.31.0, CXF clients can use proxy settings defined via quarkus.proxy.* options or refer to those via new quarkus.cxf.client."client-name".proxy-configuration-name configuration option.

Therefore, the original proxy configuration options are deprecated since Quarkus CXF 3.31.0 and will be removed in Quarkus CXF 4.0.0:

Before Quarkus CXF 3.31.0, when a SOAP client using the default VertxHttpClientHTTPConduitFactory and having quarkus.cxf.client."client-name".version = 2 and the trust store set up properly in the configuration communicated with a HTTP/2-only server (such as Vert.x with new HttpServerOptions().setUseAlpn(true).setAlpnVersions(List.of(HttpVersion.HTTP_2))), then the server hanged up unexpectedly in the middle of the conversation. This was caused by the fact that the client was sending the Connection header which is not compliant with HTTP/2. Since Quarkus CXF 3.31.0, the client is not sending the Connection header if the protocol is HTTP/2.

Before Quarkus CXF 3.31.0, when an application depended on both io.quarkiverse.cxf:quarkus-cxf-rt-ws-security and io.quarkus:quarkus-messaging-kafka then the native compilation filed with the named error. This was caused by the fact that some CXF modules reference Spring classes that are not available with Quarkus CXF.

Since Quarkus CXF 3.31.0, the CXF code referencing Spring classes is eliminated at build time using bytecode transformation.