Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 1. Release notes for Red Hat build of Apache Camel for Quarkus 3.20 / 3.20.4.SP2

1.1. Red Hat build of Apache Camel for Quarkus features
링크 복사

Fast startup and low RSS memory
Using the optimized build-time and ahead-of-time (AOT) compilation features of Quarkus, your Camel application can be pre-configured at build time resulting in fast startup times.
Application generator
Use the Quarkus application generator to bootstrap your application and discover its extension ecosystem.
Highly configurable

All the important aspects of a Red Hat build of Apache Camel for Quarkus application can be set up programmatically with CDI (Contexts and Dependency Injection) or by using configuration properties. By default, a CamelContext is configured and automatically started for you.

Check out the Configuring your Quarkus applications by using a properties file guide for more information on the different ways to bootstrap and configure an application.

Integrates with existing Quarkus extensions
Red Hat build of Apache Camel for Quarkus provides extensions for libraries and frameworks that are used by some Camel components which inherit native support and configuration options.

1.2. Supported platforms, configurations, databases, and extensions
링크 복사

For information about supported platforms, configurations, and databases in Red Hat build of Apache Camel for Quarkus version 3.20, see the Supported Configuration page on the Customer Portal (login required).

For a list of Red Hat Red Hat build of Apache Camel for Quarkus extensions and the Red Hat support level for each extension, see the Extensions Overview chapter of the Red Hat build of Apache Camel for Quarkus Reference (login required).

1.3. BOM files for Red Hat build of Apache Camel for Quarkus
링크 복사

  • To configure your Red Hat Red Hat build of Apache Camel for Quarkus version 3.20 projects to use the supported extensions, use the latest Bill Of Materials (BOM) version 3.20.4.SP2-redhat-00001 or newer, from the Redhat Maven Repository.

For more information about BOM dependency management, see Developing Applications with Red Hat build of Apache Camel for Quarkus

1.4. Technology preview extensions
링크 복사

Items designated as Technology Preview in the Extensions Overview chapter of the Red Hat build of Apache Camel for Quarkus Reference have limited supportability, as defined by the Technology Preview Features Support Scope.

1.5. Product errata and security advisories
링크 복사

1.5.1. Red Hat build of Apache Camel for Quarkus
링크 복사

For the latest Red Hat build of Apache Camel for Quarkus product errata and security advisories, see the Red Hat Product Errata page.

1.5.2. Red Hat build of Quarkus
링크 복사

For the latest Red Hat build of Quarkus product errata and security advisories, see the Red Hat Product Errata page.

1.6. JUnit breaking changes in Red Hat build of Apache Camel for Quarkus version 3.20
링크 복사

In Quarkus 3.20.1, JUnit was upgraded from 5.10 to 5.12.

This upgrade changees the behavior of reflection and inheritance of annotated methods because a different search algorithm is used.

If your unit test suites rely on the old behavior, you need to change your tests to take the new behavior into account.

You can emulate with the new JUnit version by setting the reflection parameter: 

-Djunit.platform.reflection.search.useLegacySemantics=true
Copy to Clipboard Toggle word wrap

For details, see the New Features and Improvements section in the JUnit 5.11.0 release documentation.

1.7. Known issues
링크 복사

1.7.1. Refactored .endChoice() behavior with Java DSL
링크 복사

The endChoice method is changed to end().endChoice() (see CEQ-11181).

When using Choice EIP then in some situations you may need to use .endChoice() to be able to either continue added more nodes to the current Choice EIP, or that you are working with nested Choice EIPs (choice inside choice), then you may also need to use endChoice to go back to the parent choice to continue from there.

However, there has been some regressions from upgrading older Camel releases to 4.11, and therefore we have refactored endChoice to work more consistent.

For example, the following code: 

from("direct:start")
    .choice()
        .when(header("foo").isGreaterThan(1))
            .choice()
                .when(header("foo").isGreaterThan(5))
                    .to("mock:big")
                .otherwise()
                    .to("mock:med")
            .endChoice()
        .otherwise()
            .to("mock:low")
        .end();
Copy to Clipboard Toggle word wrap

Should now be: 

from("direct:start")
    .choice()
        .when(header("foo").isGreaterThan(1))
            .choice()
                .when(header("foo").isGreaterThan(5))
                    .to("mock:big")
                .otherwise()
                    .to("mock:med")
            .end().endChoice()
        .otherwise()
            .to("mock:low")
        .end();
Copy to Clipboard Toggle word wrap

The change of endChoice method to end().endChoice() makes the calls consistent.

This ends the current (inner) choice and changes the scope to Choice EIP to be able to continue in the previous (outer) choice.

This informs Java DSL that the scope is Choice EIP and you can add the otherwise block to the outer choice, which would otherwise not work.

1.7.2. Websocket + Knative does not work with HTTP2
링크 복사

We support both camel-quarkus-grpc and camel-vertx-websocket with Knative.

gRPC needs HTTP2 (you can find instructions on how to enable it here: HTTP2 on Knative).

Unfortunately, Websockets with Knative does not work with HTTP2 (see Ingress Operator in OpenShift Container Platform).

Consequently, if you have an application that is intended to accept WebSocket connections, it must not allow negotiating the HTTP/2 protocol or else clients will fail to upgrade to the WebSocket protocol.

1.7.3. Error when running maven update
링크 복사

When running a maven update with a specified version: 

mvn com.redhat.quarkus.platform:quarkus-maven-plugin:3.20.4.SP2-redhat-00001:update -Drewrite
Copy to Clipboard Toggle word wrap

This can cause an error similar to this: 

Failed to apply the updates: The project is missing the Quarkus platform BOM in module foo.
Copy to Clipboard Toggle word wrap

The affected modules are specific to your project, so you need to read the error message to find the affected modules.

Workaround

To avoid the error, add the quarkus-resteasy dependency to the modules mentioned in the error message.

In our example, the foo module, add the dependency to foo/pom.xml: 

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-resteasy</artifactId>
</dependency>
Copy to Clipboard Toggle word wrap

1.8. Important notes
링크 복사

1.8.1. Support for IBM Power and IBM Z
링크 복사

Red Hat build of Apache Camel for Quarkus is supported on IBM Power and IBM Z.

1.8.2. Minimum Java version - JDK 17
링크 복사

Red Hat build of Apache Camel for Quarkus version 3.20 requires JDK 17 or newer.

1.8.3. Support for OpenJDK
링크 복사

Red Hat build of Apache Camel for Quarkus version 3.20 includes support for OpenJDK 21.

1.8.4. Support for AdoptiumJDK
링크 복사

Red Hat build of Apache Camel for Quarkus version 3.20 includes support for AdoptiumJDK 17 and AdoptiumJDK 21.

1.9. Camel upgraded from version 4.8 to version 4.10
링크 복사

1.9.1. Upgrading Camel from version 4.8 to version 4.10
링크 복사

For important information about upgrading Camel, see the Apache Camel manual sections:

1.9.2. Camel release notes from version 4.8 to version 4.10
링크 복사

Red Hat build of Apache Camel for Quarkus version 3.20 has been upgraded from Camel version 4.8 to Camel version 4.10. For additional information about each intervening Camel patch release, refer to the following:

1.10. Camel Quarkus upgraded from version 3.15 to version 3.20
링크 복사

Red Hat build of Apache Camel for Quarkus version 3.20 has been upgraded from Camel Quarkus version 3.8 to Camel Quarkus version 3.20. For additional information about each intervening Camel Quarkus patch release, refer to the following:

1.11. Resolved issues
링크 복사

The following lists shows known issues that were affecting Red Hat build of Apache Camel for Quarkus, which have been fixed in Red Hat build of Apache Camel for Quarkus version 3.20.

Expand
Table 1.1. Red Hat build of Apache Camel for Quarkus resolved issues in version 3.20.4.SP2
 IssueDescription

1

CEQ-12238

Failover in ClusteredRoutePolicyFactory using the FileLockClusterService is unreliable when running multiple JVMs

Expand
Table 1.2. Red Hat build of Apache Camel for Quarkus resolved issues in version 3.20.4.SP1
 IssueDescription

2

CEQ-12242

CVE-2025-66566 lz4-java: Information Disclosure via Insufficient Output Buffer Clearing

Expand
Table 1.3. Red Hat build of Apache Camel for Quarkus resolved issues in version 3.20.3
 IssueDescription

1

CEQ-11181

EIP: endChoice() cannot get the parent in nested choices

2

CEQ-11708

CVE-2025-58056 netty-codec-http: Netty is vulnerable to request smuggling due to incorrect parsing of chunk extensions

3

CEQ-11711

CVE-2025-58056 netty-codec-http2: Netty is vulnerable to request smuggling due to incorrect parsing of chunk extensions

4

CEQ-11650

Split Brain in Camel Master with File Cluster Service.

Expand
Table 1.4. Red Hat build of Apache Camel for Quarkus resolved issues in version 3.20.2.SP1
 IssueDescription

1

CEQ-11593

CVE-2025-55163 netty-codec-http2: Netty MadeYouReset HTTP/2 DDoS Vulnerability

Expand
Table 1.5. Red Hat build of Apache Camel for Quarkus resolved issues in version 3.20.1.SP1
 IssueDescription

1

CEQ-11410 / CEQ-11407

CVE-2025-48734 quarkus-cxf-bom: Apache Commons BeanUtils: PropertyUtilsBean does not suppress an enum’s declaredClass property by default

2

CEQ-11414

CAMEL-22125 camel-platform-http-vertx - Writing response should favour input stream over ByteBuffer

3

CEQ-11420

CAMEL-22130 camel-platform-http-vertx - Add timeout option

Expand
Table 1.6. Red Hat build of Apache Camel for Quarkus resolved issues in version 3.20.0
 IssueDescription

1

CEQ-10290

expose api to override opentelemetry trace id for camel route

2

CEQ-10667

The "quarkus-camel-bom-3.15.2.redhat-00003.pom" is missing artifact "io.quarkiverse.artemis/quarkus-test-artemis"

3

CEQ-10977

CAMEL-21884 Backport Request

4

CEQ-11165

Camel Quarkus JPA can not work with the named persistence unit

5

CEQ-11227

CAMEL-22001 camel-core - Kamelet and EIPs should propagate exchange variables

6

CEQ-11300

CAMEL-21495 Backport Request: camel-quarkus: REST route inlining works incorrectly when testing

1.12. Deprecated features in Red Hat build of Apache Camel for Quarkus version 3.20
링크 복사

The following capabilities are not available in the next major release of Red Hat build of Apache Camel for Quarkus, and are deprecated in this release.

1.12.1. camel-quarkus-jolokia register-management-endpoint default changed to false
링크 복사

When using camel-quarkus-jolokia, the /q/jolokia Quarkus management endpoint is no longer registered by default. It has been deprecated for removal in a future release.

If you need to restore the previous behavior and expose /q/jolokia, you can add the following to application.properties. 

quarkus.camel.jolokia.register-management-endpoint=true
Copy to Clipboard Toggle word wrap

However, as mentioned above, this option will eventually be removed.

1.13. Extensions added in Red Hat build of Apache Camel for Quarkus version 3.20
링크 복사

The following table lists the extensions added in the Red Hat build of Apache Camel for Quarkus version 3.20 release .

Expand
Table 1.7. Added extensions
 ExtensionArtifactDescription

1

CICS

camel-quarkus-cics

Interact with IBM CICS systems.

2

Groovy

camel-quarkus-groovy

Evaluate a Groovy script.

3

Jolokia

camel-quarkus-jolokia

Expose runtime metrics and management operations via JMX with Jolokia.

4

Observability services

camel-quarkus-observability-services

Camel Observability Services.

5

Olingo4

camel-quarkus-olingo4

Communicate with OData 4.0 services using Apache Olingo OData API.

6

Smooks

camel-quarkus-smooks

Use Smooks to transform, route, and bind both XML and non-XML data, including EDI, CSV, JSON, and YAML.

7

SSH

camel-quarkus-ssh

Execute commands on remote hosts using SSH.

1.14. Extensions removed in Red Hat build of Apache Camel for Quarkus version 3.20
링크 복사

No extensions are removed in the Red Hat build of Apache Camel for Quarkus version 3.20 release.

The following table lists the extensions that have changed support levels in the Red Hat build of Apache Camel for Quarkus version 3.20 release.

Expand
 ExtensionArtifactDescription

8

AWS Secrets Manager

camel-quarkus-aws-secrets-manager

Manage AWS Secrets Manager services using AWS SDK version 2.x.

9

Azure Key Vault

camel-quarkus-azure-key-vault

Manage secrets and keys in Azure Key Vault Service.

10

Azure Event Bus

camel-quarkus-azure-servicebus

Send and receive messages to/from Azure Event Bus.

11

Beanio

camel-quarkus-beanio

Marshal and unmarshal Java beans to and from flat files (such as CSV, delimited, or fixed length formats).

12

Flink

camel-quarkus-flink

Send DataSet jobs to an Apache Flink cluster.

13

Google Secret Manager

camel-quarkus-google-secret-manager

Manage Google Secret Manager Secrets

14

JQ

camel-quarkus-jq

Evaluates a JQ expression against a JSON message body.

15

Kubernetes

camel-quarkus-kubernetes

Perform operations against Kubernetes API

Note

For information about support levels, see Red Hat build of Apache Camel for Quarkus Extensions

1.16. Data formats added in Red Hat build of Apache Camel for Quarkus version 3.20
링크 복사

No data formats have been added in the Red Hat build of Apache Camel for Quarkus version 3.20 release.

1.17. Aggregated Quarkus CXF release notes 3.15.3 LTS 3.20.2 LTS
링크 복사

This section may help when upgrading from the 3.15 LTS stream to 3.20 LTS stream.

1.17.1. Important dependency upgrades
링크 복사

1.17.2. New and noteworthy in Quarkus CXF
링크 복사

1.17.2.1. #1486 TLS Registry support
링크 복사

Quarkus TLS registry is an extension provided by Quarkus that centralizes the TLS configuration, making it easier to manage and maintain secure connections across your application.

Note

io.quarkus:quarkus-tls-registry is a transitive dependency of io.quarkiverse.cxf:quarkus-cxf since Quarkus CXF 3.16.0, so you do not have to add it manually.

Quarkus TLS registry is the new recommended way of configuring trust stores, keystores and other TLS/SSL related settings in Quarkus CXF 3.16.0+:

application.properties

# Define a TLS configuration with name "hello-tls"
1 

quarkus.tls.hello-tls.trust-store.p12.path = client-truststore.pkcs12
quarkus.tls.hello-tls.trust-store.p12.password = client-truststore-password

# Basic client settings
quarkus.cxf.client.hello.client-endpoint-url = https://localhost:${quarkus.http.test-ssl-port}/services/hello
quarkus.cxf.client.hello.service-interface = io.quarkiverse.cxf.it.security.policy.HelloService

# Use "hello-tls" defined above for this client
quarkus.cxf.client.hello.tls-configuration-name = hello-tls
Copy to Clipboard Toggle word wrap

1
The referenced client-truststore.pkcs12 file has to be available either in the classpath or in the file system.

All client-related options provided by Quarkus TLS registry are supported for Vert.x based CXF clients.

1.17.2.1.1. Limitations with other clients
링크 복사

The named TLS configurations provided by TLS registry can be also used for CXF clients having http-conduit-factory set to URLConnectionHTTPConduitFactory, HttpClientHTTPConduitFactory or with Async CXF clients on top of Apache HttpClient 5. However, in those cases, the following TLS options are not supported and using them will lead to an exception at runtime:

1.17.2.1.2. Deprecated stores
링크 복사

The older way of configuring client trust stores and key stores is still supported, but deprecated since Quarkus CXF 3.16.0:

application.properties

# Deprecated way of setting the client trust store
quarkus.cxf.client.hello.trust-store-type = pkcs12
quarkus.cxf.client.hello.trust-store = client-truststore.pkcs12
quarkus.cxf.client.hello.trust-store-password = client-truststore-password
Copy to Clipboard Toggle word wrap

1.17.2.2. Vert.x HttpClient based HTTP Conduit is the new default
링크 복사

Vert.x HttpClient based HTTP Conduit was introduced in Quarkus CXF 3.13.0. Its usage was optional through setting the VertxHttpClientHTTPConduitFactory on either of the options quarkus.cxf.client."client-name".http-conduit-factory or quarkus.cxf.http-conduit-factory:

application.properties

# Before Quarkus CXF 3.16.0, VertxHttpClientHTTPConduitFactory had to be set explicitly
# Set the HTTPConduitFactory per-client
quarkus.cxf.client."client-name".http-conduit-factory = VertxHttpClientHTTPConduitFactory
# Set the HTTPConduitFactory globally
quarkus.cxf.http-conduit-factory = VertxHttpClientHTTPConduitFactory
Copy to Clipboard Toggle word wrap

Since then, it went through some improvements and testing so that we are now confident to make it default.

The main motivations for using Vert.x HttpClient based HTTP Conduit as a default are as follows:

  • Support for HTTP/2
  • Seamless integration with Quarkus, especially in the areas of worker thread poolling and SSL/TLS configuration.
1.17.2.2.1. Force the old default
링크 복사

Before this change, the effective default was URLConnectionHTTPConduitFactory. It is still supported and tested regularly.

You can get back to the old default in any one of three ways:

  1. Set the QUARKUS_CXF_DEFAULT_HTTP_CONDUIT_FACTORY environment variable to URLConnectionHTTPConduitFactory
  2. Set the global quarkus.cxf.http-conduit-factory option to URLConnectionHTTPConduitFactory
  3. Set the per client quarkus.cxf.client."client-name".http-conduit-factory option to URLConnectionHTTPConduitFactory

Since Quarkus CXF 3.16.0, setting quarkus.cxf.client."client-name".hostname-verifier together with using the default VertxHttpClientHTTPConduitFactory leads to an exception at runtime.

The AllowAllHostnameVerifier value of that option can be replaced by using a named TLS configuration with hostname-verification-algorithm set to NONE.

Here is an example: if your configuration before Quarkus CXF 3.16.0 was as follows

application.properties

# A configuration that worked before Quarkus CXF 3.16.0
quarkus.cxf.client.helloAllowAll.client-endpoint-url = https://localhost:8444/services/hello
quarkus.cxf.client.helloAllowAll.service-interface = io.quarkiverse.cxf.it.security.policy.HelloService
quarkus.cxf.client.helloAllowAll.trust-store = client-truststore.pkcs12
quarkus.cxf.client.helloAllowAll.trust-store-password = secret
quarkus.cxf.client.helloAllowAll.hostname-verifier = AllowAllHostnameVerifier
Copy to Clipboard Toggle word wrap

then an equivalent configuration for Quarkus CXF 3.16.0+ is

application.properties

# An equivalent configuration for Quarkus CXF 3.16.0+
quarkus.tls.helloAllowAll.trust-store.p12.path = client-truststore.pkcs12
quarkus.tls.helloAllowAll.trust-store.p12.password = secret
quarkus.tls.helloAllowAll.hostname-verification-algorithm = NONE
quarkus.cxf.client.helloAllowAll.client-endpoint-url = https://localhost:8444/services/hello
quarkus.cxf.client.helloAllowAll.service-interface = io.quarkiverse.cxf.it.security.policy.HelloService
quarkus.cxf.client.helloAllowAll.tls-configuration-name = helloAllowAll
Copy to Clipboard Toggle word wrap

1.17.2.3. #1447 Support asynchronous mode with VertxHttpClientHTTPConduit
링크 복사

Before Quarkus CXF 3.17.0, CXF clients based on VertxHttpClientHTTPConduit could only be called synchronously: 

@CXFClient("hello")
HelloService hello;

String callHello() {
    // Synchronous CXF client call
    hello.hello("Joe");
}
Copy to Clipboard Toggle word wrap

Quarkus CXF 3.17.0 introduces the asynchronous mode for VertxHttpClientHTTPConduit-based clients: 

import io.smallrye.mutiny.Uni;

@CXFClient("hello")
HelloService hello;

Uni<String> callHelloAsync() {
    return Uni.createFrom()
            // Asynchronous CXF client call returning java.util.concurrent.Future
            .future(hello.helloAsync("Joe"))
            .map(HelloResponse::getReturn);
}
Copy to Clipboard Toggle word wrap

This works much like with the existing Apache HttpClient 5 Async HTTP Transport. The main difference is that you do not need to add (now deprecated) io.quarkiverse.cxf:quarkus-cxf-rt-transports-http-hc5 dependency to your application anymore.

You still need to generate the async methods using the embedded wsdl2java tool.

Check the Asynchronous client page for more information.

1.17.2.4. #1609 Support HTTP redirects with VertxHttpClientHTTPConduit
링크 복사

Before Quarkus CXF 3.17.0, the VertxHttpClientHTTPConduit-based CXF clients were not following HTTP redirects (HTTP status codes 301, 302, 303 and 307 with Location response header) even if quarkus.cxf.client."client-name".auto-redirect was enabled for the given client.

Quarkus CXF 3.17.0 adds this functionality along with the proper support for quarkus.cxf.client."client-name".max-retransmits.

A new configuration property quarkus.cxf.client."client-name".redirect-relative-uri was introduced. It is equivalent to setting http.redirect.relative.uri property on the CXF client request context as already supported by CXF.

1.17.2.5. #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.

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:

Tip

The above configuration options also works for URLConnectionHTTPConduit.

1.17.2.7. #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, 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:

Before Quarkus CXF 3.19.0, it was only possible to configure trust stores and key stores per CXF client via quarkus.cxf.client."client-name".tls-configuration-name or (now deprecated) quarkus.cxf.client."client-name".key-store* and quarkus.cxf.client."client-name".trust-store* options.

In cases with multiple clients, this configuration could get verbose.

Since Quarkus CXF 3.19.0, it is possible to set the trust stores and key stores for all clients using the quarkus.cxf.client.tls-configuration-name option.

1.17.3. Bugfixes
링크 복사

Before Quarkus CXF 3.19.0, combining quarkus-jdbc-oracle with quarkus-cxf-integration-tracing-opentelemetry or quarkus-cxf-rt-ws-rm in a single application resulted in an error during the build of native image as follows: 

org.graalvm.compiler.debug.GraalError: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException:
Detected a MBean server in the image heap. This is currently not supported, but could be changed in the future.
Management beans are registered in many global caches that would need to be cleared and properly re-built at image build time.
Class of disallowed object: com.sun.jmx.mbeanserver.JmxMBeanServer
Copy to Clipboard Toggle word wrap

We have fixed this in Quarkus CXF 3.19.0.

Note

JMX features are still not supported in native mode.

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. This would mean that only one set of those classes, suiting only one of those services was 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)
Copy to Clipboard Toggle word wrap

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.

1.17.4. Deprecations
링크 복사

1.17.4.1. #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.

1.17.4.2. #1632 io.quarkiverse.cxf:quarkus-cxf-rt-transports-http-hc5 deprecated
링크 복사

The io.quarkiverse.cxf:quarkus-cxf-rt-transports-http-hc5 extension is deprecated since Quarkus CXF 3.19.0 and it is scheduled for removal in 3.21.0. Use the asynchronous mode of VertxHttpClientHTTPConduit instead.

This is a part of our efforts to support only a single HTTP Conduit based on Vert.x HttpClient in the future.

1.17.4.3. Deprecated configuration properties
링크 복사

1.17.5. Full changelog
링크 복사

https://github.com/quarkiverse/quarkus-cxf/compare/3.15.3...3.20.2

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat맨 위로 이동