Chapter 1. Red Hat build of Apache Camel for Spring Boot 4.10 release notes


1.1. Features in Red Hat build of Apache Camel for Spring Boot

Red Hat build of Apache Camel for Spring Boot introduces Camel support for Spring Boot which provides auto-configuration of Camel, and starters for many Camel components. The opinionated auto-configuration of the Camel context auto-detects Camel routes available in the Spring context and registers key Camel utilities (like producer template, consumer template and the type converter) as beans.

1.2. Supported platforms, configurations, databases, and extensions for Red Hat build of Apache Camel for Spring Boot

1.3. The javax to jakarta Package Namespace Change

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.3.1. Migration tools

1.4. Important notes for Red Hat build of Apache Camel for Spring Boot

1.4.1. Support for IBM Power and IBM Z

Red Hat build of Camel Spring Boot is now supported on IBM Power and IBM Z.

1.4.2. Changes to the snowdrop groupId

The snowdrop groupId is changed from me.snowdrop to dev.snowdrop. You must update the pom.xml file accordingly.

1.4.3. Using the automatic Camel context reloading on Secret Refresh feature of AWS Secret Manager component starter

To use the Automatic Camel context reloading on Secret Refresh feature, the secret update has to be done either via UI or via API call with opereation PutSecretValue. The camel context reload will not be triggered with executing updateSecret via Camel.

1.5. Fixed issues for Red Hat build of Apache Camel for Spring Boot

The following sections list the issues that have been resolved in Red Hat build of Apache Camel for Spring Boot.

1.5.1. Red Hat build of Apache Camel for Spring Boot version 4.10 fixed issues

The following sections list the issues that have been resolved in Red Hat build of Apache Camel for Spring Boot version 4.10.

Table 1.1. Red Hat build of Apache Camel for Spring Boot version 4.10 resolved issues
IssueDescription

CSB-4171

Add support for camel-graphql

CSB-4661

Support for plain CXF SOAP scenarios

CSB-4995

Add support for Kamelets and Pipes

CSB-5483

Odd behaviour of <toD> with header substitution

CSB-5648

jaxws:client’s address placeholder is not getting resolved when configured in XML

CSB-5823

Redshift kamelet: Failed to configure a DataSource

CSB-5875

camel-platform-http-starter does not implement all the features in restConfiguration

CSB-6248

camel-jaxb - JaxbDataFormat ignoreJAXBElement is default true

CSB-6282

Create an example of the implementation for Camel’s Route Security using Spring Security

CSB-6304

[Doc] Lack of instruction to install SAP JCo and SAP IDoc libraries into the "lib/" directory of the Java runtime on OCP

CSB-6358

Support component camel-observability-services

CSB-6464

Additional Information Needed in CamelLivenessStateHealthIndicator Logs

CSB-6466

javax dependencies on camel-kubernetes

CSB-6469

Support component camel-ssh

CSB-6527

camel-infinispan-starter doesn’t work with latest productized JDG

CSB-6687

Support component camel-smooks

CSB-6739

Dependency org.apache.camel/camel-console increases the building times

CSB-6742

Red Hat Build of Apache Camel BOM includes UPSTREAM Artemis BOM

CSB-6761

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

CSB-6766

strimzi quickstart / get rid of kubernetes profile

CSB-6812

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

CSB-6855

kamelets: camel export fails due to Bean not found

CSB-6865

[AWS-Kinesis] Error on kinesisClient bean when using KCL Consumer mode

CSB-6936

jbang export causes java.lang.ClassNotFoundException: org.apache.camel.kamelets.catalog.KameletsCatalog

CSB-6943

Kamelet ExtractField references wrong Camel ExtractField class

CSB-6946

MongoDB version is misaligned

CSB-6955

CVE-2025-1948 jetty-http2-common: Jetty HTTP/2 Header List Size Vulnerability

RHBAC-127

Backport CAMEL-21828: Fix DefaultHeaderFilterStrategy when filtering in lower-case mode

RHBAC-142

Backport CAMEL-21876 - Undertow Header Filter Strategy: Considering also the in filter

RHBAC-145

Camel CLI export command does not treat the product version

1.6. API changes for Red Hat build of Apache Camel for Spring Boot

The following sections list known issues for Red Hat build of Apache Camel for Spring Boot.

1.6.1. Red Hat build of Apache Camel for Spring Boot version 4.10.3 changes API

CSB-6748 Method AttachmentMessage.getAttachments() return value changed
When you use the method AttachmentMessage.getAttachments() it returns an empty list instead of the null value when there are no attachments.

1.7. Known issues for Red Hat build of Apache Camel for Spring Boot

The following sections list known issues for Red Hat build of Apache Camel for Spring Boot.

1.7.1. Red Hat build of Apache Camel for Spring Boot version 4.10.3 known issues

CSB-6748 Method AttachmentMessage.getAttachments() return value changed
When you use the method AttachmentMessage.getAttachments() it returns an empty list instead of the null value when there are attachments.

1.7.2. Red Hat build of Apache Camel for Spring Boot version 4.8.3 known issues

CSB-6437 CXF opentelemetry - using same trace id from different http requests on RHEL9
This issue only occurs with CXF and OpenTelemetry with the custom tracing configuration on RHEL 9 platform. ,In case of CXF and opentelemetry with the custom opentelemetry tracer defined, when you call multiple requests, the trace ID seems to be reused in the Camel routes. The result is that new spans are added in the existing traces for each http request, instead of creating one new trace ID for each http request. The workaround is to explicitly define the ContextPropagators to W3CTraceContextPropagator as shown in the example below:
    @Bean
    ContextPropagators contextPropagators() {
       // return ContextPropagators.create(TextMapPropagator.composite(W3CBaggagePropagator.getInstance()));
       return ContextPropagators.create(W3CTraceContextPropagator.getInstance());
    }
Copy to Clipboard

1.7.3. Red Hat build of Apache Camel for Spring Boot version 4.8.0 known issues

CSB-4318 Fail to deploy on OCP using Openshift Maven Plugin if spring.boot.actuator.autoconfigure is not in the dependencies

Jkube maven plugin uses the following condition to check if the application exposes health endpoint (using SpringBootHealthCheckEnricher). Both classes are in the classpath:

  • org.springframework.boot.actuate.health.HealthIndicator
  • org.springframework.web.context.support.GenericWebApplicationContext

However, the /actuator/health wil be not exposed without the configuration of the actuator. This creates discordance between the readiness/liveness probes configured by JKube (they both uses the above endpoint) and what the application is exposing.

This misconfiguration causes a failing deployment config on OpenShift Container Platform since the generated pod will never be in Ready status since the probe`s call for an endpoint is not configured. So in order to make the application work on OpenShift Container Platform, which is deployed using JKube (openshift-maven-plugin), it is necessary to have both web and actuator autoconfiguration in the dependencies.

Following example shows how to configure web and actuator autoconfiguration.

Example

<dependency>
 <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Copy to Clipboard

Update the archetype as shown below. The applications built from the following archetype will be deployed correctly using JKube.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
      <exclusion>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-tomcat</artifactId>
      </exclusion>
    </exclusions>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Copy to Clipboard

This issue affects the custom applications with missing one of the above dependencies.

Back to top
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

© 2025 Red Hat