Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 1. Release notes for Red Hat build of Apache Camel for Quarkus 3.8 / 3.8.6.SP2

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.
  • For information about supported platforms, configurations, and databases in Red Hat build of Apache Camel 4.4 for Quarkus 3 GA, 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).
  • To configure your Red Hat Red Hat build of Apache Camel for Quarkus version 3.8 projects to use the supported extensions, use the latest Bill Of Materials (BOM) version 3.8.6.SP2-redhat-00002 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
Copy link

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
Copy link

1.5.1. Red Hat build of Apache Camel for Quarkus
Copy link

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
Copy link

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

1.6. Known issues
Copy link

Compiling a native project can result in a NoClassDefFoundError like this: 

Caused by: java.lang.NoClassDefFoundError: io/netty/handler/codec/socksx/v5/Socks5InitialRequest
at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1160)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.classinitialization.ClassInitializationSupport.ensureClassInitialized(ClassInitializationSupport.java:177)
... 55 more
Caused by: java.lang.ClassNotFoundException: io.netty.handler.codec.socksx.v5.Socks5InitialRequest
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
Copy to Clipboard Toggle word wrap

The reason is that netty-codec-socks is excluded in the quarkus-qpid-jms extension, which camel-quarkus-amqp depends on.

Workaround
You can avoid the errror by manually adding the netty-codec-socks depencency.

1.6.2. Issues with Quarkus on AArch64 systems
Copy link

There currently are problems and limitations with Quarkus 3.8 on AArch64 systems. For more information, see the release notes for Red Hat build of Quarkus 3.8:

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.6.4. Other known issues
Copy link

Quarkus native compilation of camel-quarkus-jackson-avro fails

If you try to compile a Camel Quarkus application that uses the camel-quarkus-jackson-avro extension to native code, the compilation fails with an UnsupportedFeatureException error.

As a workaround, you can build the application with camel-quarkus-jackson-avro extension using the parameter -Dquarkus.native.additional-build-args=--initialize-at-run-time=org.apache.avro.file.DataFileWriter or add that configuration property to your src/main/resources/application.properties file.

For more information, see the support article "Quarkus native compilation of camel-quarkus-jackson-avro fails" in the customer portal. (Login required)

Moving from smallrye-metrics to camel-quarkus-micrometer requires manual registration of beans

If you are migrating to micrometer from smallrye-metrics, you may need to manually define some beans as scoped.

In smallrye-metrics, classes that are registered for metrics (for example with @COUNTED, @METRIC), but not registered as scoped beans, are registered automatically. This does not happen in micrometer.

In micrometer you need to manually register beans accessed via CDI, by for example adding a @Dependent annotation.

Camel-quarkus-snmp not supported in Native
In Red Hat build of Apache Camel for Quarkus we support the camel-quarkus-snmp component in JVM mode only.

1.7. Known Quarkus CXF issues
Copy link

Note

CXF is fully supported, but the following issues remain with this release of Red Hat build of Apache Camel for Quarkus.

If there are two SEIs in one Java package, both having a @WebMethod with the same name but different signature, then the default name for the generated request, response and possibly other classes is the same for both methods of both classes.

As of Quarkus CXF 3.8.3, no exception is thrown when this happens during the class generation at build time. At runtime, only one set of those classes is present and therefore calls to one of the clients fail inevitably.

The @CXFEndpoint annotation was mistakenly introduced in Red Hat build of Apache Camel for Quarkus 3.8.4.SP2 and Quarkus CXF 3.8.4. It is reverted in the of Red Hat build of Apache Camel for Quarkus 3.8 and Quarkus CXF 3.8.5.

The annotation allows you to specify CXF service endpoint paths through the new annotation @CXFEndpoint("/myPath").

This does not work well for service implementation classes having both @WebService and @CXFEndpoint annotations. In those cases, if the service has some @Inject fields, those fields are left blank and the service call throws a NullPointerException.

Service implementations that do not have the @CXFEndpoint annotations are unaffected.

We recommend that you continue to specify service endpoint paths in application.properties as before:

Example

quarkus.cxf.endpoint."/myPath".implementor = org.acme.MyServiceImpl
Copy to Clipboard Toggle word wrap

1.9. Important notes
Copy link

The Java EE move to the Eclipse Foundation and the establishment of Jakarta EE, since Jakarta EE 9, packages used for all EE APIs have changed to jakarta.*

Code snippets in documentation have been updated to use the jakarta.* namespace, but you of course need to take care and review your own applications.

Note

This change does not affect javax packages that are part of Java SE.

When migrating applications to EE 10, you need to:

  • Update any import statements or other source code uses of EE API classes from the javax package to jakarta.
  • Change any EE-specified system properties or other configuration properties whose names begin with javax. to begin with jakarta..
  • Use the META-INF/services/jakarta.[rest_of_name] name format to identify implementation classes in your applications that use the implement EE interfaces or abstract classes bootstrapped with the java.util.ServiceLoader mechanism.

1.9.1.1. Migration tools
Copy link

Additional resources

1.9.2. Support for IBM Power and IBM Z
Copy link

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

1.9.3. Minimum Java version - JDK 17
Copy link

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

1.9.4. Support for OpenJDK
Copy link

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

1.9.5. Support for AdoptiumJDK
Copy link

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

1.10. Upgrades
Copy link

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

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

1.11. Resolved issues
Copy link

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.8.

1.11.1. Resolved issues in Quarkus CXF 3.8.6
Copy link

Before Quarkus CXF 3.8.6, the values specified in quarkus.cxf.codegen.wsdl2java.package-names

quarkus.cxf.codegen.wsdl2java.package-names were wrongly passed as a single comma-separated value of the -p option, leading to BadUsageException: -p has invalid character!.

Since Quarkus CXF 3.8.6, if quarkus.cxf.codegen.wsdl2java.package-names specifies multiple mappings, such as

application.properties

quarkus.cxf.codegen.wsdl2java.package-names =
  http://www.example.org/add=io.quarkiverse.cxf.wsdl2java.it.add,
  http://www.example.org/multiply=io.quarkiverse.cxf.wsdl2java.it.multiply
Copy to Clipboard Toggle word wrap

then they are properly passed to wsdl2java as multiple -p options: 

wsdl2java \
  -p http://www.example.org/add=io.quarkiverse.cxf.wsdl2java.it.add \
  -p http://www.example.org/multiply=io.quarkiverse.cxf.wsdl2java.it.multiply \
  ...
Copy to Clipboard Toggle word wrap

When backporting fixes from the main branch of Quarkus CXF to 3.8, we mistakenly ported a new feature allowing to specify CXF service endpoint paths through the new annotation @CXFEndpoint("/myPath").

The new code did not work well for service implementation classes having both @WebService and @CXFEndpoint annotations.

In those cases, if the service has some @Inject fields, those fields ere left blank and the service call throws a NullPointerException.

Service implementations not using the new @CXFEndpoint annotations are unaffected.

The code introducing the new @CXFEndpoint("/myPath") functionality was removed in this release.

We recommend that you continue to specify service endpoint paths in application.properties, for example:

Example

quarkus.cxf.endpoint."/myPath".implementor = org.acme.MyServiceImpl
Copy to Clipboard Toggle word wrap

CEQ-8857
Camel-http producer sets "Content-Encoding=UTF-8"

1.11.3. Previous releases
Copy link

For details of issues resolved between Camel Quarkus 3.2 and Camel Quarkus 3.8, see the Release Notes for each patch release.

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. Openapi-java support for Openapi v2
Copy link

Deprecated features

OpenApi V2 is deprecated in 3.8, due to dropped support in Openapi-java with Camel 4.5.x.

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

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

Expand
Table 1.1. Added extensions
ExtensionArtifactDescription

Jasypt

camel-quarkus-jasypt

Security using Jasypt

JSON Path

camel-quarkus-jsonpath

Evaluate a JSONPath expression against a JSON message body

JT400

camel-quarkus-jt400

Exchanges messages with an IBM i system using data queues, message queues, or program call. IBM i is the replacement for AS/400 and iSeries servers.

Kudu

camel-quarkus-kudu

Interact with Apache Kudu, a free and open source column-oriented data store of the Apache Hadoop ecosystem.

LRA

camel-quarkus-lra

Camel saga binding for Long-Running-Action framework.

Saga

camel-quarkus-saga

Execute custom actions within a route using the Saga EIP.

Splunk HEC

camel-quarkus-splunk-hec

The splunk component allows to publish events in Splunk using the HTTP Event Collector.

XJ

camel-quarkus-xj

Transform JSON and XML message using a XSLT.

No extensions have changed support levels in the Red Hat build of Apache Camel for Quarkus version 3.8 release.

Note

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

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

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top