Quarkus CXF 3.35.0 release notes
Important dependency upgrades
-
CXF 4.1.5 → 4.2.0 - release notes
-
Quarkus 3.33.1 → 3.34.5 - release notes
-
Apache HTTP Client 5.5.1 → 5.5.2 and HTTP Core 5.3.6 → 5.4.2
-
Ehcache 3.11.1 → 3.12.0
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);We used this code ourselves in our integration tests.
The same code is used by QuarkusCxfTestUtil.getClient(…) methods that we exposed for public usage in
Quarkus CXF 3.33.0.
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 and 3.33.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.
IllegalFormatConversionException in a debug log statement in CxfMutinyUtils
Before Quarkus CXF 3.35.0 and 3.33.2, a debug log statement in CxfMutinyUtils used a %d format to log
a non-number object, which could cause a java.util.IllegalFormatConversionException at runtime.
Since Quarkus CXF 3.35.0 and 3.33.2, the correct %s format specifier is used.
Stop warning about non-loadable CXF Bus extensions at build time
Before Quarkus CXF 3.35.0 and 3.33.2, non-loadable CXF Bus extensions were logged at WARN level at build time.
The WARN level is not appropriate, because some missing classes are expected at build time,
due to exclusion of some transitive dependencies from CXF.
Since Quarkus CXF 3.35.0 and 3.33.2, those messages are logged at DEBUG level.