Apache Camel 4.x Upgrade Guide

The library used for Camel Grok component has been migrated from no more maintained io.krakens:java-grok to its fork io.github.whatap:java-grok. It implies small differences listed here.

The org.apache.camel.support.DefaultHeaderFilterStrategy changed default setting for lowercase from false to true.

The type converters for Java serialized objects with types java.io.ObjectInput and java.io.ObjectOutput has been removed. Java object serialization is a recurring source of security issues and therefore these converters has been removed. These converters are not used at all by Camel itself. To restore compatibility then end users can add these type converters back as custom converters in their own Camel applications. However, using Java serialization is discouraged and highly recommend to use other means.

Removed org.apache.camel.spi.ReifierStrategy which is no longer in use by Camel and can safely be removed.

A new getChildren() default method has been added to org.apache.camel.NamedNode. It returns List<NamedNode> and provides a uniform API for traversing the route model tree, including structural nodes like WhenDefinition and OtherwiseDefinition that are not ProcessorDefinition subclasses and therefore invisible to getOutputs(). Code that walks the model tree recursively should prefer getChildren() over getOutputs() to avoid needing special-case handling for Choice EIP.

The NamedNode.getLevel() and getParentId() methods no longer treat when and otherwise nodes as "shallow". Previously these nodes were flattened to the same level as their parent choice, which was inconsistent with how doCatch and doFinally work inside doTry. Now when and otherwise contribute their own level, consistent with the tree structure exposed by getChildren(). This affects level values reported via JMX (ManagedProcessor.getLevel()) and dev consoles for nodes inside Choice EIP branches.

The camel wrapper command now installs the scripts as camel instead of camelw. You can use the --command-name=camelw to use the old name.

A new canonical JSON Schema variant (camelYamlDsl-canonical.json) has been added alongside the existing classic schema (camelYamlDsl.json). The canonical schema removes all implicit patterns (string shorthands, inline expressions, oneOf/anyOf/not constructs) to provide a simpler, more predictable schema for tooling such as IDEs, code generators, and AI assistants. See the YAML DSL documentation for details.

The YamlValidator class now accepts a boolean canonical constructor parameter to validate against the canonical schema.

A new camel yaml normalize command has been added to Camel JBang. It rewrites YAML routes from the classic (shorthand) form to the canonical (explicit) form. The camel validate yaml command also supports a new --canonical flag to validate against the canonical schema.

When using camel-kafka-starter with Spring Boot, the standard spring.kafka. properties are now automatically bridged to the Camel Kafka component configuration (CAMEL-22760). This means you no longer need to duplicate Kafka settings under both spring.kafka. and camel.component.kafka.*.

The bridged properties include bootstrap-servers, security.protocol, SSL/TLS settings (keystore, truststore), consumer.group-id, client-id, and SASL properties (sasl.mechanism, sasl.jaas.config, sasl.kerberos.service.name).

Explicit camel.component.kafka.* settings always take precedence over the bridged Spring Boot values.

The bridge is enabled by default. To disable it, set:

The default ObjectInputFilter pattern that ships with the components listed below has been tightened to explicitly deny classes under java.net. before allowing the rest of java., javax. and org.apache.camel.. The previous default did not deny java.net.**, which meant classes whose hashCode/equals methods perform network I/O (notably java.net.URL and java.net.InetAddress) could be deserialized by the in-code default.

Affected components:

The new default is:

(or !java.net.;java.;org.apache.camel.;!* for the aggregation repository components, which do not include javax.).

The endpoint-level option deserializationFilter and the JVM-wide system property -Djdk.serialFilter continue to override this default. Applications that have a legitimate need to deserialize java.net.URL or other java.net.* types must configure an explicit filter.

For production deployments handling untrusted serialized payloads, the in-code filter is intended as defense-in-depth only. The primary mitigation should be configured at the messaging provider:

JMS ObjectMessage support is now disabled by default. Java object serialization is a recurring source of security issues, and Camel JMS routes rarely use ObjectMessage in practice. The component will now refuse to create or read jakarta.jms.ObjectMessage instances unless the new objectMessageEnabled option is explicitly set to true.

This affects the following endpoint/component options that rely on ObjectMessage internally:

To restore the previous behavior, enable the option at the component or endpoint level:

Or, on a single endpoint:

The same default applies to camel-sjms (and camel-sjms2, which inherits from it): JMS ObjectMessage support is now disabled by default and gated by a new objectMessageEnabled option (default false) on SjmsComponent / SjmsEndpoint.

This affects the same endpoint/component options as camel-jms:

To restore the previous behavior, enable the option at the component or endpoint level:

Or, on a single endpoint:

Hazelcast instances created and managed by Camel (when no user-supplied Config or HazelcastInstance is provided) now apply a default JavaSerializationFilterConfig on the SerializationConfig of the Config built by Camel. The default whitelists the class name prefixes java., javax., org.apache.camel. and blacklists java.net..

This affects:

A user-supplied JavaSerializationFilterConfig (set on the SerializationConfig of a Config provided via hazelcastConfigUri, a referenced Config bean, or already wired into a pre-built HazelcastInstance) is respected and is not overwritten.

Applications that store classes outside the default whitelist on a Hazelcast topic, queue, map, list, set, or in one of the repositories above must provide their own Config with a JavaSerializationFilterConfig configured for their class names.

Camel stomp was deprecated with Camel 4.17. The stomp library didn’t have any activities in the last 10 years. The component is now removed.

Camel AWS X-Ray was deprecated with Camel 4.17. Amazon Web Services X-Ray service is in maintenance mode since February 2026. The component is now removed.

Camel Guava EventBus was deprecated with Camel 4.6. The component is now removed.

Camel Grape was deprecated with Camel 4.1. The component is now removed.

Camel Grape was deprecated with Camel 4.0. The component is now removed.

If you have custom telemetry implementations, the following interfaces have changed:

In order to prevent a potential leak when running asynchronous components we need to rethink the implementation details of camel-opentelemetry2 and remove the Scope wrapping that, when asynchronous, was opening the Scope in a thread and closing in another (what we had called "dirty" context). We are now removing this wrapping and moving this part exclusively in the custom Camel Processors. Here Camel will take care to open the Opentelemetry scope and close it within the same thread.

What it means is that, from now on, the final user or any third party dependency can only "control" the Opentelemetry context within the boundary of a Processor execution.

This is just an informative note, there is not action expected by the final user.

The component camel-ironmq is deprecated. The official library used has been unmaintained since 2017 All the other client libraries (in other languages) are unmaintained since the same amount of time. The whole iron-io GitHub organization has almost no activity.

The component camel-digitalocean is deprecated. The java library used has been unmaintained for several years and there is no replacement.

The component camel-irc is deprecated. The library used had no stable release since 2007. There is no Java library very active for this protocol.