Quarkus CXF 3.33.0 LTS release notes

3.33.0 is the first release in the 3.33 long term support (LTS) stream.

Important dependency upgrades

Enhancements

#2064 QuarkusCxfTestUtil - a new utility for testing Quarkus CXF

QuarkusCxfTestUtil offers static methods to create a SOAP client for testing. This is handy especially in native mode, 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.

Here 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 tested and officially supported.

Bugfixes

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.