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
-
Quarkus 3.32.x → 3.33.0 - release notes
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.