Aggregated Quarkus CXF release notes 3.27.2 LTS → 3.33.3 LTS

This document may help when upgrading from the 3.27 LTS stream to 3.33 LTS stream.

Important dependency upgrades

Enhancements

New keep alive configuration options

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

#1943 Configure HTTP or SOCKS proxies via Quarkus Proxy Registry

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:

#2064 QuarkusCxfTestUtil - a new utility for testing Quarkus CXF

QuarkusCxfTestUtil offers static methods to create a SOAP client for testing. This is useful in native mode tests (having @io.quarkus.test.junit.QuarkusIntegrationTest annotation), where injecting client beans to test classes is not possible.

QuarkusCxfTestUtil is hosted by a new artifact io.quarkiverse.cxf:quarkus-cxf-test-util that is managed in quarkus-cxf-bom.

The following is an example QuarkusCxfTestUtil usage:

import io.quarkiverse.cxf.test.QuarkusCxfTestUtil;
import org.assertj.core.api.Assertions;
...
HelloService helloClient = QuarkusCxfTestUtil.getClient(
        "https://acme.org/hello", // the target namespace of HelloService
                                  // can be omitted if HelloService class
                                  // is annotated with @WebService(targetNamespace="...")
        HelloService.class, // the service endpoint interface (SEI)
        "/services/hello" // the path to append to base URL on which Quarkus test instance is listening
    );

Assertions.assertThat(helloClient.hello("Dolly"))
        .isEqualTo("Hello Dolly!");

#2058 Java 25 support

Java 25 is now supported.

Bugfixes

#1997 Vert.x-based SOAP client cannot communicate with HTTP/2-only server

Before Quarkus CXF 3.31.0, when a SOAP client using the default VertxHttpClientHTTPConduitFactory and having quarkus.cxf.client."client-name".version = 2 communicated with a HTTP/2-only server, the server hung 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.

#1945 ClassNotFoundException: org.springframework.beans.BeansException during native compilation

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 failed with the named error. Since Quarkus CXF 3.31.0, the CXF code referencing Spring classes is eliminated at build time using bytecode transformation.

Start measuring receive timeout after the HTTP connection is ready

Before Quarkus CXF 3.33.0, when using the default VertxHttpClientHTTPConduit, the measurement of the receive timeout defined via quarkus.cxf.client."client-name".receive-timeout started when the request was queued for a free connection. As a consequence of that, the receive time span may have overlapped the connect time span and receive timeouts may have come earlier than expected.

Since Quarkus CXF 3.33.0, the receive timeout is measured starting from when the HTTP connection is ready, rather than from when the request is created and queued for a free connection. This provides more accurate receive timeout behavior.

#2060 Avoid using HttpClientHTTPConduit even for clients created via jakarta.xml.ws.Service.create(URL, QName).getPort(MyService.class)

HttpClientHTTPConduit provided by CXF has had known issues, so we deprecated the HttpClientHTTPConduitFactory value of quarkus.cxf.http-conduit-factory and quarkus.cxf.client."client-name".http-conduit-factory options in 3.18.0 release. We removed the HttpClientHTTPConduitFactory value in Quarkus CXF 3.22.0. So after 3.22.0 it was not possible to create an injected SOAP client via Quarkus CXF application.properties configuration that would use HttpClientHTTPConduit and JDK HTTP Client under the hood.

However, even after Quarkus CXF 3.22.0 it was still possible to programmatically create SOAP clients using HttpClientHTTPConduit as follows:

URL serviceUrl = ...;
QName qName = ...
Service service = Service.create(serviceUrl, qName);
MyService myClient = service.getPort(MyService.class);

We used this code ourselves in our integration tests. The same code is used by QuarkusCxfTestUtil.getClient(…​) methods that we exposed for public usage in Quarkus CXF 3.33.0.

The issue #2060 popped up in our MTOM integration test, which spawns many SOAP clients to perform some soak testing. When the number of clients went over certain threshold, the clients started failing due to underlying HTTP connections being closed. This is another known issue of JDK HTTP client: no external control over its internal connection pool is possible. Connections may get closed while SOAP clients still use them, possibly running in parallel threads.

Since Quarkus CXF 3.33.2, even clients created programmatically via jakarta.xml.ws.Service.create(URL, QName).getPort(MyService.class) are using URLConnectionHTTPConduit instead of HttpClientHTTPConduit. As a consequence of that, no issues with connection pooling should occur.

IllegalFormatConversionException in a debug log statement in CxfMutinyUtils

Before Quarkus CXF 3.33.2, a debug log statement in CxfMutinyUtils used a %d format to log a non-number object, which could cause a java.util.IllegalFormatConversionException at runtime. Since Quarkus CXF 3.33.2, the correct %s format specifier is used.

Stop warning about non-loadable CXF Bus extensions at build time

Before Quarkus CXF 3.33.2, non-loadable CXF Bus extensions were logged at WARN level at build time. The WARN level is not appropriate, because some missing classes are expected at build time, due to exclusion of some transitive dependencies from CXF. Since Quarkus CXF 3.33.2, those messages are logged at DEBUG level.

Deprecations

Old proxy configuration options deprecated

Since Quarkus CXF 3.31.0, CXF clients can use proxy settings defined via quarkus.proxy.* options or refer to those via the option quarkus.cxf.client."client-name".proxy-configuration-name.

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

Full changelog

https://github.com/quarkiverse/quarkus-cxf/compare/3.27.2...3.33.3