Quarkus CXF 3.18.0 release notes
Important dependency upgrades
-
Quarkus 3.17.x → 3.18.0 - release notes
-
CXF 4.0.5 → 4.1.0 - release notes, changelog
New features
#1639 Add quarkus.cxf.client."client-name".max-same-uri
configuration option
Check `quarkus.cxf.client."client-name".max-same-uri’s documentation for more information.
Special thanks to @dcheng1248 for the contribution.
#1628 Support offloading the request data to disk with VertxHttpClientHTTPConduit
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:
The above configuration options work also for |
Bugfixes
#1685 VertxHttpClientHTTPConduit
based client hangs when run asynchronously on Vert.x event loop with a body exceeding single chunk
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.
Deprecations
#1633 HttpClientHTTPConduitFactory
value of *.http-conduit-factory
deprecated
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.
Documentation improvements
-
We started using
AntorAssured
for validating external links and internal cross-references in our documentation, so dead links became much less likely. -
Removed dangling experimental status from
VertxHttpClientHTTPConduitFactory
in the ducumentation ofquarkus.cxf.http-conduit-factory
andquarkus.cxf.client."client-name".http-conduit-factory