Quarkus CXF 3.27.2 LTS release notes

Important dependency upgrades

Bugfixes

#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, due to which 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);

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. Therefore it may happen that the connections get closed while SOAP clients, possibly running in parallel threads still use them.

Since Quarkus CXF 3.35.0, 3.33.2 and 3.27.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.

Full changelog

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