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 camel-api module now has an optional dependency on org.jspecify:jspecify for null safety annotations (@NullMarked, @Nullable). The dependency is <optional>true</optional>, so it is not pulled transitively into your application. The annotations are used to document nullability contracts across the Camel API surface and enable compile-time null checking with tools like NullAway. If you want to leverage these annotations in your own code or tooling, add org.jspecify:jspecify explicitly to your project dependencies.

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

README files (README.md, README.adoc, etc.) are now included when running integrations with camel run. Previously these files were silently excluded. The README files are added to the classpath and exposed via the CLI connector so tools such as camel monitor can display them.

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.

The camel run and camel export commands now auto-detect application.properties (and profile-specific variants such as application-prod.properties) in the current directory and include them automatically. Previously you had to explicitly list the properties file on the command line (e.g. camel run hello.java application.properties). This is no longer required.

When camel.main.routesReloadEnabled=true (automatically set by camel run --dev), Camel now auto-disables contentCache on resource-based components (such as xslt) whose default is true, so that edits to the resource file are picked up on the next message without restarting the route. Set camel.component.<name>.contentCache=true (or pass ?contentCache=true on the URI) to opt back in to caching during dev mode.

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.

Camel now logs a WARN message when YAML DSL routes use compact (shorthand) notation instead of the canonical form. This encourages adopting the canonical style which is more tooling and AI friendly. The warning is logged once per resource file. To disable this warning, set camel.main.yamlDslCompactNotationWarn = false in application.properties.

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.

Camel GitHub was deprecated with Camel 4.18. The component is now removed. There is camel-github2 to replace it. Technically, camel-github was based on Eclipse EGit which is no more active. camel-github2 is based on org.kohsuke:github-api.

In order to prevent some potential span leakage in camel-opentelemetry2 (see notes below) we had to perform some changes and introduce the following parameter:

This is required in order to distinguish the older traceProcessors parameter which now accounts exclusively for custom processors. Keeping the default parameter (false) could increase the number of spans generated, though, this is required to guarantee consistency and memory sealing. If you need to reduce the number of spans for any reason you can explicitly provide exclusion configuration.

In this version we have also changed certain interfaces, so, if you have custom telemetry implementations, you may need to adjust to them:

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 nlp/word_embedding application no longer ships a built-in zoo predictor. The only zoo model previously listed for this application — ai.djl.mxnet:glove:0.0.2 — relied on the discontinued Apache MXNet engine and never loaded successfully (the corresponding integration test had been permanently @Disabled). The ZooWordEmbeddingPredictor class has been removed and the nlp/word_embedding branch of ModelPredictorProducer.getZooPredictor now reports Application not supported for that path.

Routes that use a custom word-embedding model (no artifactId, with explicit model and translator parameters) are unaffected — CustomWordEmbeddingPredictor and the nlp/word_embedding branch of getCustomPredictor remain in place.

The applyGuardrail producer operation now reads the guardrail identifier from a new dedicated header CamelAwsBedrockGuardrailIdentifier (constant BedrockConstants.GUARDRAIL_IDENTIFIER, typed String) instead of CamelAwsBedrockGuardrailConfig. The CamelAwsBedrockGuardrailConfig header is typed GuardrailConfiguration and is reserved for the converse and converseStream operations; the previous code path silently produced null whenever a route mixed converse and applyGuardrail calls. If you were not setting the guardrail identifier via header, the endpoint-level guardrailIdentifier option continues to work without changes.

The Exchange header constants in JGroupsConstants have been renamed to follow the Camel naming convention used across the rest of the component catalog. The Java field names are unchanged; only the header string values have changed:

This is a breaking change for routes that read or write these headers by their literal string value. Routes that reference the constant symbolically (for example setHeader(JGroupsConstants.HEADER_JGROUPS_DEST, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("JGROUPS_DEST", …​)) must be updated to use the new value (setHeader("CamelJGroupsDest", …​)).

The Exchange header constants in ElasticSearchRestClientConstant have been renamed to follow the Camel naming convention used across the rest of the component catalog. The Java field names are unchanged; only the header string values have changed:

Routes that reference the constant symbolically (for example setHeader(ElasticSearchRestClientConstant.SEARCH_QUERY, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("SEARCH_QUERY", …​)) must be updated to use the new value (setHeader("CamelElasticsearchSearchQuery", …​)).

The Exchange header constants in CxfConstants (module camel-cxf-common, shared by camel-cxf and camel-cxfrs) have been renamed to follow the Camel naming convention used across the rest of the component catalog. The Java field names are unchanged; only the header string values have changed:

Routes that reference the constant symbolically (for example setHeader(CxfConstants.OPERATION_NAME, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("operationName", …​)) must be updated to use the new value (setHeader("CamelCxfOperationName", …​)).

In particular, the documented cxfrs SimpleConsumer dispatch idiom that routes on the operation name by its literal header name must be updated:

The Exchange header constants in DnsConstants have been renamed to follow the Camel naming convention used across the rest of the component catalog. The Java field names are unchanged; only the header string values have changed:

Routes that reference the constant symbolically (for example setHeader(DnsConstants.DNS_SERVER, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("dns.server", …​) or setHeader("term", …​)) must be updated to use the new value:

The two Exchange header prefix constants in SolrConstants have been renamed to follow the Camel naming convention already used by the other constants in the same file (which were renamed in 4.10 under CAMEL-21697). The Java field names are unchanged; only the prefix string values have changed:

Routes that reference the constants symbolically (for example setHeader(SolrConstants.HEADER_FIELD_PREFIX + "id", …​)) continue to work without changes. Routes that set the headers by their literal string value (for example setHeader("SolrField.id", …​) or setHeader("SolrParam.commit", …​)) must be updated to use the new prefix (CamelSolrField.id, CamelSolrParam.commit).

Because the renamed prefixes now begin with Camel, they are stripped by the standard transport HeaderFilterStrategy (HttpHeaderFilterStrategy, etc.) when crossing a transport boundary, by design — Camel* headers are framework-internal and are not propagated over the wire. Routes that bridge an external transport (HTTP, JMS, …​) into a solr: producer and want to drive Solr document fields or query parameters from a header supplied by the sender must therefore carry the value in a non-Camel-prefixed application header and map it to the appropriate CamelSolrField. / CamelSolrParam. header in the route between the transport from and the solr: to.

The listObjects operation now uses the ListObjectsV2 AWS API instead of the deprecated ListObjects API. If you use pojoRequest=true with operation=listObjects, you must change your request and response types:

The non-POJO path (header-based configuration) is updated automatically and requires no changes.

Fixed the JetStream consumer pull subscription mode (which is the default) so that messages are actually consumed from the server. Previously the consumer would set up a pull subscription but never issue any pull/fetch requests, so no messages were delivered until the user explicitly switched to push mode with pullSubscription=false.

Two new endpoint options have been added to control the pull fetch loop:

The default headerFilterStrategy is now a new NatsHeaderFilterStrategy that filters headers starting with Camel / camel (case-insensitive) in both the inbound and outbound directions, aligning the component with the rest of the Camel component catalog (camel-kafka, camel-mail, camel-coap, camel-google-pubsub, …​). Routes that relied on passing through these header names from NATS messages can supply a custom headerFilterStrategy to restore the previous behaviour.

The default headerFilterStrategy is now a new XmppHeaderFilterStrategy that filters headers starting with Camel / camel (case-insensitive) in both the inbound and outbound directions, aligning the component with the rest of the Camel component catalog (camel-kafka, camel-mail, camel-coap, camel-google-pubsub, …​). Routes that relied on passing through these header names from XMPP messages can supply a custom headerFilterStrategy to restore the previous behaviour.

The Exchange header values exposed by LuceneConstants have been renamed to follow the standard Camel naming convention. The field names are unchanged, so routes referencing the constants (LuceneConstants.HEADER_QUERY, LuceneConstants.HEADER_RETURN_LUCENE_DOCS) continue to work without modification. However, routes that set or read these headers using the raw string values must be updated:

As a consequence, the generated Endpoint DSL header accessors on LuceneHeaderNameBuilder have been renamed accordingly:

The Exchange header values exposed by CouchDbConstants have been renamed to follow the standard Camel naming convention. The field names are unchanged, so routes referencing the constants (e.g. CouchDbConstants.HEADER_METHOD, CouchDbConstants.HEADER_DOC_ID) continue to work without modification. However, routes that set or read these headers using the raw string values must be updated:

The generated Endpoint DSL header accessors on CouchDbHeaderNameBuilder retain the same method names but now return the updated CamelCouchDb* values. No code changes are needed if you use these accessors.

The Exchange header values exposed by CouchbaseConstants have been renamed to follow the standard Camel naming convention. The field names are unchanged, so routes referencing the constants (e.g. CouchbaseConstants.HEADER_ID, CouchbaseConstants.HEADER_TTL) continue to work without modification. However, routes that set or read these headers using the raw string values must be updated:

As a consequence, the generated Endpoint DSL header accessors on CouchbaseHeaderNameBuilder have been renamed accordingly:

The Exchange header constants in JGroupsRaftConstants have been renamed to follow the Camel naming convention used across the rest of the component catalog. The Java field names are unchanged; only the header string values have changed:

Routes that reference the constant symbolically (for example setHeader(JGroupsRaftConstants.HEADER_JGROUPSRAFT_SET_TIMEOUT, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("JGROUPSRAFT_SET_TIMEOUT", …​)) must be updated to use the new value (setHeader("CamelJGroupsRaftSetTimeout", …​)).

The Exchange header constants in JiraConstants have been renamed to follow the Camel naming convention used across the rest of the component catalog. The Java field names are unchanged; only the header string values have changed:

Routes that reference the constants symbolically (for example setHeader(JiraConstants.ISSUE_KEY, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("IssueKey", …​)) must be updated to use the new value (setHeader("CamelJiraIssueKey", …​)).

As a consequence, the generated Endpoint DSL header accessors on JiraHeaderNameBuilder have been renamed accordingly:

The vertx-websocket consumer now applies a HeaderFilterStrategy to the WebSocket query and path parameters before mapping them into the Camel message headers. The new default VertxWebsocketHeaderFilterStrategy filters headers starting with Camel / camel (case-insensitive) in both the inbound and outbound directions, aligning the component with the rest of the Camel component catalog (camel-coap, camel-kafka, camel-nats, …​). A new headerFilterStrategy endpoint option is available; routes that relied on receiving Camel-prefixed header names from WebSocket query or path parameters can supply a custom headerFilterStrategy to restore the previous behaviour.

The atmosphere-websocket consumer now applies the endpoint HeaderFilterStrategy to the WebSocket query parameters before mapping them into the Camel message headers. The inherited default HttpHeaderFilterStrategy filters headers starting with Camel / camel (case-insensitive). Routes that relied on receiving Camel-prefixed header names from WebSocket query parameters can supply a custom headerFilterStrategy to restore the previous behaviour.

The iggy consumer now applies a HeaderFilterStrategy to the Iggy message user-headers before mapping them into the Camel message headers. The new default IggyHeaderFilterStrategy filters headers starting with Camel / camel (case-insensitive) in both the inbound and outbound directions, aligning the component with the rest of the Camel component catalog. A new headerFilterStrategy endpoint option is available; routes that relied on receiving Camel-prefixed user-header names from Iggy messages can supply a custom headerFilterStrategy to restore the previous behaviour.

The three Exchange header constants in ShiroSecurityConstants that drive Shiro authentication used header values outside the Camel namespace (SHIRO_SECURITY_TOKEN, SHIRO_SECURITY_USERNAME, SHIRO_SECURITY_PASSWORD) and were therefore not filtered by the default HeaderFilterStrategy. They have been renamed to follow the Camel naming convention. The Java field names are unchanged; only the header string values have changed:

These headers carry credentials and a serialized authentication token, so filtering them at transport boundaries by default is particularly important.

Routes that reference the constants symbolically (for example setHeader(ShiroSecurityConstants.SHIRO_SECURITY_USERNAME, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("SHIRO_SECURITY_USERNAME", …​)) must be updated to use the new value (setHeader("CamelShiroSecurityUsername", …​)).

The Exchange header constants in Web3jConstants have been renamed to follow the Camel naming convention used across the rest of the component catalog. The Java field names are unchanged; only the header string values have changed:

Routes that reference the constants symbolically (for example setHeader(Web3jConstants.FROM_ADDRESS, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("FROM_ADDRESS", …​)) must be updated to use the new value (setHeader("CamelWeb3jFromAddress", …​)).

The Web3jConstants.ETH_HASHRATE constant is dual-purpose: it is both the CamelWeb3jOperation value that dispatches the ethHashrate RPC and the header name read by the ETH_SUBMIT_HASHRATE operation. Routes that referenced the literal string "ETH_HASHRATE" (in either role) must be updated to "CamelWeb3jEthHashrate". Routes using the symbolic constant reference are unaffected. The other producer-dispatch operation identifiers (WEB3_CLIENT_VERSION, ETH_GAS_PRICE, ETH_SEND_TRANSACTION, …​) keep their previous string values because they are operation enum values rather than Exchange header names.

As a consequence, the generated Endpoint DSL header accessors on Web3jHeaderNameBuilder have been renamed accordingly:

A new accessor web3jOperation() is also generated for Web3jConstants.OPERATION (the producer dispatch header). This constant did not appear in the catalog previously, so no DSL accessor renaming applies to it.

The Exchange header constants in OpenstackConstants, KeystoneConstants, NovaConstants, CinderConstants, GlanceConstants, NeutronConstants, and SwiftConstants have been renamed to follow the Camel naming convention used across the rest of the component catalog. The Java field names are unchanged; only the header string values have changed.

Common constants (in OpenstackConstants):

Keystone (KeystoneConstants):

Nova (NovaConstants):

Cinder (CinderConstants):

Glance (GlanceConstants):

Neutron (NeutronConstants):

Swift (SwiftConstants):

SwiftConstants.CONTAINER_METADATA_PREFIX, SwiftConstants.VERSIONS_LOCATION, SwiftConstants.CONTAINER_READ, and SwiftConstants.CONTAINER_WRITE intentionally keep their previous values (X-Container-Meta-, X-Versions-Location, X-Container-Read, X-Container-Write) because they are part of the Swift HTTP protocol contract used by openstack4j to forward container metadata and ACLs to the Swift backend. Renaming them would break interoperability with the Swift API.

Routes that reference the constants symbolically (for example setHeader(OpenstackConstants.OPERATION, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("operation", …​)) must be updated to use the new value (setHeader("CamelOpenstackOperation", …​)).

The generated Endpoint DSL header accessors on each component’s HeaderNameBuilder are renamed accordingly (operation() → openstackOperation(), password() → openstackKeystonePassword(), adminPassword() → openstackNovaAdminPassword(), etc.).

The Exchange header constants in PdfHeaderConstants have been renamed to follow the Camel naming convention used across the rest of the component catalog. The Java field names are unchanged; only the header string values have changed:

Routes that reference the constants symbolically (for example setHeader(PdfHeaderConstants.PDF_DOCUMENT_HEADER_NAME, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("pdf-document", …​)) must be updated to use the new value (setHeader("CamelPdfDocument", …​)).

As a consequence, the generated Endpoint DSL header accessors on PdfHeaderNameBuilder have been renamed accordingly:

The Exchange header constants in ElasticsearchConstants and OpensearchConstants have been renamed to follow the Camel naming convention used across the rest of the component catalog. The Java field names are unchanged; only the header string values have changed.

ElasticsearchConstants:

OpensearchConstants:

ElasticsearchConstants.PROPERTY_SCROLL_ES_QUERY_COUNT and OpensearchConstants.PROPERTY_SCROLL_OPENSEARCH_QUERY_COUNT were already Camel-prefixed (CamelElasticsearchScrollQueryCount / CamelOpenSearchScrollQueryCount) and are unchanged.

Routes that reference the constants symbolically (for example setHeader(ElasticsearchConstants.PARAM_INDEX_NAME, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("indexName", …​)) must be updated to use the new value (setHeader("CamelElasticsearchIndexName", …​)).

The generated Endpoint DSL header accessors on ElasticsearchHeaderNameBuilder and OpensearchHeaderNameBuilder have been renamed accordingly (operation() → elasticsearchOperation() / opensearchOperation(), indexId() → elasticsearchIndexId() / opensearchIndexId(), etc.).

The producer-side Exchange header constants in GitHub2Constants have been renamed to follow the Camel naming convention used across the rest of the component catalog. The Java field names are unchanged; only the header string values have changed:

The consumer-side constants (GITHUB_COMMIT_AUTHOR, GITHUB_COMMIT_COMMITTER, GITHUB_COMMIT_SHA, GITHUB_COMMIT_URL, GITHUB_EVENT_PAYLOAD) were already Camel-prefixed (CamelGitHubCommitAuthor, etc.) and are unchanged, as is the GITHUB_CLIENT registry-lookup key (github2Client).

Routes that reference the constants symbolically (for example setHeader(GitHub2Constants.GITHUB_PULLREQUEST, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("GitHubPullRequest", …​)) must be updated to use the new value (setHeader("CamelGitHubPullRequest", …​)).

As a consequence, the generated Endpoint DSL header accessor gitHubPullRequestHeadCommitSHA() on GitHub2HeaderNameBuilder has been renamed to gitHubPullRequestHeadCommitSha(). The remaining accessors (gitHubPullRequest(), gitHubInResponseTo(), gitHubIssueTitle()) keep their names but now return the new Camel-prefixed values.

The Exchange header constants in these Google Cloud components carried a GoogleCloud<Service> / GoogleSecretManager prefix that is not in the Camel namespace, so the default HeaderFilterStrategy did not filter them at transport boundaries. They have been renamed to add the Camel prefix. The Java field names are unchanged; only the header string values have changed:

The GoogleSecretManagerConstants.SECRET_ID, VERSION_ID and REPLICATION constants were already Camel-prefixed (CamelGoogleSecretManagerSecretId, etc.) and are unchanged.

Routes that reference the constants symbolically (for example setHeader(GoogleCloudFunctionsConstants.OPERATION, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("GoogleCloudFunctionsOperation", …​)) must be updated to use the new value (setHeader("CamelGoogleCloudFunctionsOperation", …​)).

The generated Endpoint DSL header accessor names are unchanged (for example googleCloudFunctionsOperation()), since the Camel prefix is stripped when deriving the accessor name; the accessors now return the new Camel-prefixed values.

Two Exchange header constants in ArangoDbConstants that were not in the Camel namespace (and therefore not filtered by the default HeaderFilterStrategy) have been renamed to follow the Camel naming convention. The Java field names are unchanged; only the header string values have changed:

The remaining constants (MULTI_UPDATE, MULTI_INSERT, MULTI_DELETE, AQL_QUERY, AQL_QUERY_BIND_PARAMETERS, AQL_QUERY_OPTIONS) were already Camel-prefixed and are unchanged.

Routes that reference the constants symbolically (for example setHeader(ArangoDbConstants.ARANGO_KEY, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("key", …​)) must be updated to use the new value (setHeader("CamelArangoDbKey", …​)).

As a consequence, the generated Endpoint DSL header accessors on ArangoDbHeaderNameBuilder have been renamed: key() → arangoDbKey() and resultClassType() → arangoDbResultClassType().

The two Exchange header constants in Jt400Constants that were not in the Camel namespace (and therefore not filtered by the default HeaderFilterStrategy) have been renamed to follow the Camel naming convention. The Java field names are unchanged; only the header string values have changed:

Jt400Constants.KEY is the data-queue key used for keyed-data-queue read and write operations. The remaining constants (MESSAGE, MESSAGE_ID, MESSAGE_FILE, MESSAGE_TYPE, MESSAGE_SEVERITY, MESSAGE_DFT_RPY, MESSAGE_REPLYTO_KEY) were already Camel-prefixed and are unchanged.

Routes that reference the constants symbolically (for example setHeader(Jt400Constants.KEY, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("KEY", …​)) must be updated to use the new value (setHeader("CamelJt400Key", …​)).

As a consequence, the generated Endpoint DSL header accessors on Jt400HeaderNameBuilder have been renamed: kEY() → jt400Key() and senderInformation() → jt400SenderInformation().

The consumer-side dispatch header constants in MailConstants that control post-processing of a consumed mail message used header values outside the Camel namespace (copyTo, moveTo, delete) and were therefore not filtered by the default HeaderFilterStrategy. They have been renamed to follow the Camel naming convention (companion to the CAMEL-23522 mail.smtp.* hardening). The Java field names are unchanged; only the header string values have changed:

The standard RFC 5322 message header constants (MAIL_SUBJECT = Subject, MAIL_FROM = From, MAIL_TO = To, MAIL_CC = Cc, MAIL_BCC = Bcc, MAIL_REPLY_TO = Reply-To, MAIL_CONTENT_TYPE = contentType) are unchanged, as they map directly to the corresponding email fields and renaming them would break mail interoperability.

The equally-named copyTo and moveTo endpoint URI options on the mail consumer are also unchanged; only the Exchange header values are affected.

Routes that reference the constants symbolically (for example setHeader(MailConstants.MAIL_DELETE, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("delete", true)) must be updated to use the new value (setHeader("CamelMailDelete", true)).

As a consequence, the generated Endpoint DSL header accessors on MailHeaderNameBuilder have been renamed: copyTo() → mailCopyTo(), moveTo() → mailMoveTo(), and delete() → mailDelete().

The MiloConstants.HEADER_AWAIT constant, which controls whether milo-client writes are awaited, used the header value await — outside the Camel namespace and therefore not filtered by the default HeaderFilterStrategy. It has been renamed to follow the Camel naming convention. The Java field name is unchanged; only the header string value has changed:

MiloConstants.HEADER_NODE_IDS was already Camel-prefixed (CamelMiloNodeIds) and is unchanged.

Routes that reference the constant symbolically (for example setHeader(MiloConstants.HEADER_AWAIT, …​)) continue to work without changes. Routes that set the header by its literal string value (for example setHeader("await", …​)) must be updated to use the new value (setHeader("CamelMiloAwait", …​)).

As a consequence, the generated Endpoint DSL header accessor await() on MiloClientHeaderNameBuilder has been renamed to miloAwait().

The Jackson 2.x and Jackson 3.x lines ship the same dataformat names (jackson, jacksonXml, avroJackson, protobufJackson) for DSL drop-in compatibility, but their documentation pages previously shared the same filename and silently overwrote each other when the doc site was built (CAMEL-23531). The pages have been split and now carry an explicit 2 or 3 suffix:

The page titles are likewise disambiguated (JSON Jackson 2 / JSON Jackson 3, etc.) and both variants now appear in the dataformats navigation. Update any external xref: links that point at the old filenames; routes referencing the dataformats by name are unaffected.

Two new optional configuration properties are available on both camel.server. and camel.management. for the embedded HTTP server:

Both default to unset. When both are unset, JWT validation behaviour is unchanged (signature plus the default exp / nbf checks).

org.apache.camel.test.AvailablePortFinder.Port now also implements AfterEachCallback and BeforeAllCallback. When the Port is registered as a non-static @RegisterExtension field, it is automatically released after each test method, instead of leaking until JVM exit. The previous behaviour for static @RegisterExtension fields (port reserved for the whole class, released on afterAll) is preserved. Tests that manually called port.release() from an @AfterEach method to work around CAMEL-21122 no longer need that workaround.

The Exchange header values exposed by GridFsConstants have been renamed to follow the standard Camel naming convention, bringing camel-mongodb-gridfs in line with the parent camel-mongodb component (MongoDbConstants.OPERATION_HEADER = "CamelMongoDbOperation"). The Java field names are unchanged, so routes referencing the constants symbolically (e.g. GridFsConstants.GRIDFS_OPERATION, GridFsConstants.GRIDFS_OBJECT_ID) continue to work without modification. However, routes that set or read these headers using the raw string values must be updated:

As a consequence, the generated Endpoint DSL header accessors on GridFsHeaderNameBuilder have been renamed accordingly:

The commons-dbcp dependency has been removed. Even if is a very common usage with it, this is only a test dependency. In case, you are relying on it, you will need to add it to you project dependency. Note that, for our tests and examples, we migrated to use commons-dbcp2.

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.

The component camel-iec-60870 is deprecated. The library used to implement it NeoScada is no more maintained since 2021. There are no alternatives in Java with compatible license.

The org.apache.camel.component.jasypt.Main class — the command line entrypoint that lets the camel-jasypt jar be invoked directly (e.g. via JBang) to encrypt or decrypt property values — is now deprecated and will be removed in a future Camel release.

Use the standalone CLI scripts (encrypt.sh / decrypt.sh / digest.sh) shipped in the upstream jasypt-1.9.3 distribution instead. They cover the same workflow and let us drop the duplicate implementation maintained inside camel-jasypt. The component itself (property-source decryption at runtime) is unaffected.

Tool argument headers are now filtered against the tool’s declared parameter schema. When the LLM returns a tool call, only JSON field names that match a declared parameter.<name> are set as Exchange headers. Undeclared field names are logged at WARN level and skipped.

This is a breaking change for tools defined without explicit parameter.* declarations. Previously, all LLM-provided argument field names were set as Exchange headers without filtering. Now, tools with no declared parameters will have zero argument headers set from the LLM tool call.

For example, a tool defined as:

will no longer receive any LLM-provided arguments as headers. To restore argument flow, declare the expected parameters explicitly:

Additionally, camel-langchain4j-agent now extracts primitive values (int, long, double, boolean, String) from tool arguments instead of setting raw JsonNode objects as headers.

The components camel-paho is deprecated. There were no new release since 2020 of the Java client, last non-regulatory commit was in 2022.

The in-code default ObjectInputFilter shipped by the following components now includes JEP-290 graph-shape limits (maxdepth=20, maxrefs=10000, maxbytes=10485760) in addition to the existing class allowlist:

The new defaults are:

These limits provide defense-in-depth so that operators who have not set -Djdk.serialFilter still get sensible graph-shape limits out of the box. The class allowlist is unchanged.

Operators retain the existing override paths:

Routes that legitimately deserialize very deep, very wide, or very large object graphs may need to either raise the structural limits via the deserializationFilter option or via -Djdk.serialFilter, or migrate off Java serialization entirely.

Note that camel-jms and camel-sjms apply their filter as a post-deserialization class check (after the JMS provider has already decoded the payload). Graph-shape limits are therefore not meaningful in those sites and have not been added; DoS hardening on the JMS path must be configured at the JMS provider level (for example Artemis deserializationAllowList, ActiveMQ Classic SERIALIZABLE_PACKAGES) or via -Djdk.serialFilter.

A new container-level operation listBlobVersions has been added. It returns one BlobItem per version of every blob in the container, each carrying its own versionId and isCurrentVersion flag, so the full version history can be inspected. Requires versioning to be enabled on the storage account. The same prefix, regex and maxResultsPerPage filters as listBlobs are honoured.