Quarkus CXF 3.18.0 release notes

Check `quarkus.cxf.client."client-name".max-same-uri’s documentation for more information.

Special thanks to @dcheng1248 for the contribution.

Quarkus CXF 3.17.0, added support for redirects with VertxHttpClientHTTPConduit. It included some basic in-memory caching of the request body for the sake of retransmission. Since Quarkus CXF 3.18.0, the VertxHttpClientHTTPConduit is able to offload the data to disk in case the size of the body surpasses some configurable threshold. Check the documentation of the following new configuration options to learn how the new feature works:

Before Quarkus CXF 3.18.0, Quarkus CXF did not prevent calling clients in asynchronous mode on Vert.x event loop thread. However, that kind use did only work for request bodies not exceeding single HTTP chunk (configurable via quarkus.cxf.client."client-name".chunking-threshold). For larger bodies, the call would block forever.

Since Quarkus CXF 3.18.0, all asynchronous calls of VertxHttpClientHTTPConduit based clients are transparently dispatched on a Vert.x worker thread, thus preventing blocking of the Vert.x event loop.

The HttpClientHTTPConduitFactory value of quarkus.cxf.http-conduit-factory and quarkus.cxf.client."client-name".http-conduit-factory existed since their inception in Quarkus CXF 2.3.0.

HttpClientHTTPConduit never gained any real traction within Quarkus CXF. When CXF started using it as a default, we were forced to introduce our own default (URLConnectionHTTPConduitFactory) to avoid bugs like #992, CXF-8885, CXF-8951, CXF-8946, CXF-8903 and possibly others. Now that we have VertxHttpClientHTTPConduit, which we can support very well on Quarkus, there are no more reasons for us to spend our resources on HttpClientHTTPConduit.

HttpClientHTTPConduitFactory was marked as deprecated in our documentation and we added some warnings on application startup for folks still using it.