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
- For information about supported platforms, configurations, and databases in Red Hat build of Apache Camel for Spring Boot, see the Supported Configuration page on the Customer Portal (login required).
- For a list of Red Hat Red Hat build of Apache Camel for Spring Boot extensions, see the Red Hat build of Apache Camel for Spring Boot Reference (login required).
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.
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 tojakarta
. -
Change any EE-specified system properties or other configuration properties whose names begin with
javax.
to begin withjakarta.
. -
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 thejava.util.ServiceLoader
mechanism.
1.3.1. Migration tools
- Source code migration: How to use Red Hat Migration Toolkit for Auto-Migration of an Application to the Jakarta EE 10 Namespace
- Bytecode transforms: For cases where source code migration is not an option, the open source Eclipse Transformer
Additional resources
- Background: Update on Jakarta EE Rights to Java Trademarks
- Red Hat Customer Portal: Red Hat JBoss EAP Application Migration from Jakarta EE 8 to EE 10
- Jakarta EE: Javax to Jakarta Namespace Ecosystem Progress
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.
Issue | Description |
---|---|
Add support for camel-graphql | |
Support for plain CXF SOAP scenarios | |
Add support for Kamelets and Pipes | |
Odd behaviour of <toD> with header substitution | |
jaxws:client’s address placeholder is not getting resolved when configured in XML | |
Redshift kamelet: Failed to configure a DataSource | |
camel-platform-http-starter does not implement all the features in restConfiguration | |
camel-jaxb - JaxbDataFormat ignoreJAXBElement is default true | |
Create an example of the implementation for Camel’s Route Security using Spring Security | |
[Doc] Lack of instruction to install SAP JCo and SAP IDoc libraries into the "lib/" directory of the Java runtime on OCP | |
Support component camel-observability-services | |
Additional Information Needed in CamelLivenessStateHealthIndicator Logs | |
javax dependencies on camel-kubernetes | |
Support component camel-ssh | |
camel-infinispan-starter doesn’t work with latest productized JDG | |
Support component camel-smooks | |
Dependency org.apache.camel/camel-console increases the building times | |
Red Hat Build of Apache Camel BOM includes UPSTREAM Artemis BOM | |
EIP: endChoice() cannot get the parent in nested choices | |
strimzi quickstart / get rid of kubernetes profile | |
[CAMEL-22001]camel-core - Kamelet and EIPs should propagate exchange variables | |
kamelets: camel export fails due to Bean not found | |
[AWS-Kinesis] Error on kinesisClient bean when using KCL Consumer mode | |
jbang export causes java.lang.ClassNotFoundException: org.apache.camel.kamelets.catalog.KameletsCatalog | |
Kamelet ExtractField references wrong Camel ExtractField class | |
MongoDB version is misaligned | |
CVE-2025-1948 jetty-http2-common: Jetty HTTP/2 Header List Size Vulnerability | |
Backport CAMEL-21828: Fix DefaultHeaderFilterStrategy when filtering in lower-case mode | |
Backport CAMEL-21876 - Undertow Header Filter Strategy: Considering also the in filter | |
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
toW3CTraceContextPropagator
as shown in the example below:
@Bean ContextPropagators contextPropagators() { // return ContextPropagators.create(TextMapPropagator.composite(W3CBaggagePropagator.getInstance())); return ContextPropagators.create(W3CTraceContextPropagator.getInstance()); }
@Bean
ContextPropagators contextPropagators() {
// return ContextPropagators.create(TextMapPropagator.composite(W3CBaggagePropagator.getInstance()));
return ContextPropagators.create(W3CTraceContextPropagator.getInstance());
}
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>
<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>
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>
<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>
This issue affects the custom applications with missing one of the above dependencies.