Quarkus CXF 3.20.0 release notes

Important dependency upgrades

New features

#1616 Support authorization retransmits in VertxHttpClientHTTPConduit

Before Quarkus CXF 3.20.0, when a remote service responded with 401 Unauthorized or 407 Proxy Authentication Required, then clients backed by VertxHttpClientHTTPConduit would simply fail and the only possible workaround was to use some other HTTP conduit, such as URLConnectionHTTPConduit.

Since Quarkus CXF 3.20.0, VertxHttpClientHTTPConduit handles 401 and 407 status codes properly by sending a new request with an Authorization header value derived from one or more of following options:

Bugfixes

#1730 Async client fails when getting remote WSDL: IllegalStateException: You have attempted to perform a blocking service method…​

Before Quarkus CXF 3.20.0, when an asynchronous client backed by VertxHttpClientHTTPConduit that had a remote WSDL URI set via quarkus.cxf.client."client-name".wsdl, was called for the first time from a Vert.x Event Loop thread, then Quarkus CXF would reject performing the blocking operation of fetching the WSDL with the following message:

java.lang.IllegalStateException: You have attempted to perform a blocking service method call on Vert.x event loop thread
with CXF client my-client. This is not allowed, as blocking the IO thread will cause major performance issues with your
application. You need to offload the blocking CXF client call to a worker thread, e.g. by using the
@io.smallrye.common.annotation.Blocking annotation on a caller method where it is supported by the underlying Quarkus
extension, such as quarkus-rest, quarkus-vertx, quarkus-reactive-routes, quarkus-grpc, quarkus-messaging-* and possibly
others.

Since Quarkus CXF 3.20.0, the implementation of io.quarkiverse.cxf.mutiny.CxfMutinyUtils.toUni(Consumer<AsyncHandler<T>>) takes care that the Consumer call is dispatched on a worker thread if needed.

See also Callback-based asynchronous method section of Asynchronous client guide.

#1326 CXF-9003 Name clash between Service methods with the same name in one Java package

For each service method, several ancillary classes are generated at build time. These may represent a request or a response of an operation. So, for com.acme.HelloService.hello() method at least two classes com.acme.jaxws_asm.Hello and com.acme.jaxws_asm.HelloResponse would be generated. Before Quarkus CXF 3.20.0 and CXF 4.1.1, the name of the service class was not taken into account. Therefore, when there were multiple service interfaces containing methods with the same name in a single Java package, then the names for their ancillary classes would clash. Followingly, only one set of those classes, suiting only one of those services, would be stored in the application. At runtime, the following error message may appear in the application log:

java.lang.IllegalArgumentException: argument type mismatch
     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
     at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at java.base/java.lang.reflect.Method.invoke(Method.java:568)
     at org.apache.cxf.databinding.AbstractWrapperHelper.createWrapperObject(AbstractWrapperHelper.java:114)
     at org.apache.cxf.jaxws.interceptors.WrapperClassOutInterceptor.handleMessage(WrapperClassOutInterceptor.java:91)
     at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
     at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356)
     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314)
     at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
     at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140)
     at jdk.proxy6/jdk.proxy6.$Proxy132.hello(Unknown Source)

The problem was fixed in CXF 4.1.1 and Quarkus CXF 3.20.0. Now, the name of the service class is taken into account. So for the above example, the names of the generated classes would be com.acme.jaxws_asm.helloservice.Hello and com.acme.jaxws_asm.helloservice.HelloResponse respectively.

#1735 Receive timeout not honored by clients based on VertxHttpClientHTTPConduit

Before Quarkus CXF 3.20.0, when the a service client backed by VertxHttpClientHTTPConduit started reading the response body, the receive timeout set via quarkus.cxf.client."client-name".receive-timeout was not checked anymore. The operation would never fail in that phase, regardless whether the connection was slow, or the response body was large.

Since Quarkus CXF 3.21.0, the receive timeout is honored also during reading the response body.

Deprecations

Deprecated properties

Documentation improvements

Full changelog

https://github.com/quarkiverse/quarkus-cxf/compare/3.19.0...3.20.0