Apache Camel 4.x Upgrade Guide

The UseOriginalAggregationStrategy binding has been moved from Splitter and RecipientListProcessor into MulticastProcessor (their shared base class), so all three EIPs (Multicast, Splitter, RecipientList) now consistently bind the original exchange on the strategy. Previously, Multicast never called newInstance(exchange), which made the strategy silently ineffective — especially in error scenarios where the aggregated result could overwrite the original exchange body instead of preserving it.

When consuming from Azure Service Bus in PEEK_LOCK mode with maxAutoLockRenewDuration > 0, Camel now actively renews message locks using a dedicated ServiceBusReceiverAsyncClient and Camel’s internal PeriodTaskScheduler. This addresses a limitation where the Azure SDK’s built-in lock renewal is tied to the processMessage callback duration, which returns immediately for asynchronous Camel routes — causing long-running exchanges to silently lose their message locks.

The new behavior activates automatically when all of the following are true:

No configuration changes are required. The existing maxAutoLockRenewDuration option controls how long Camel will continue renewing a message’s lock.

When using HttpClient 5.6+ (including transitively via a Spring Boot BOM on Camel 4.18.x), HttpClient auto-decompresses gzip response bodies but may leave stale Content-Encoding, Content-Length, and Content-MD5 headers. Camel now reads content encoding from entity.getContentEncoding() instead of the response header and strips stale compression headers after the HTTP call. This prevents a second decompression attempt that could fail with ZipException: Not in GZIP format against gzip-compressing servers with default settings.

When unmarshalling a MIME message with headersInline=true, the mime-multipart data format now applies a HeaderFilterStrategy to the headers copied from the MIME content onto the Camel message. Camel-internal headers (the Camel* namespace, matched case-insensitively) present in the external MIME headers are no longer copied onto the message, consistent with the inbound header filtering already performed by the camel-mail consumer.

Ordinary application headers are unaffected. If a route relied on Camel* headers being propagated from the MIME content, set them explicitly after unmarshalling.

When consuming a CloudEvent in structured content mode (application/cloudevents+json), the Knative component now applies a HeaderFilterStrategy to the event fields (extensions) mapped from the payload onto the Camel message. Camel-internal headers (the Camel* namespace, matched case-insensitively) present as structured-event fields are no longer mapped onto the message, consistent with the inbound header filtering already performed on the binary content-mode / HTTP header path.

Ordinary CloudEvent extension attributes are unaffected. If a route relied on Camel*-named fields being propagated from the structured payload, set them explicitly after consuming the event.

When consuming a message with preserveHeaders=true, the IronMQ consumer now applies a HeaderFilterStrategy to the header entries embedded in the JSON message envelope before mapping them onto the Camel message. Camel-internal headers (the Camel* namespace, matched case-insensitively) present in the envelope are no longer mapped onto the message, consistent with the inbound header filtering performed by other consumers.

Ordinary application headers are unaffected. If a route relied on Camel* headers being propagated from the message envelope, set them explicitly after consuming the message.

The azure-eventhubs producer now applies a DefaultHeaderFilterStrategy to the headers copied onto EventData application properties. Camel-internal headers (the Camel* namespace, matched case-insensitively) are no longer forwarded to Azure Event Hubs, consistent with the inbound header filtering performed by other components.

Ordinary application headers are unaffected.

The Exchange header constants in WebsocketConstants 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(WebsocketConstants.CONNECTION_KEY, …​)) continue to work without changes. Routes that set the header by its literal string value must be updated to use the new value.

The camel-jackson data format now creates its default ObjectMapper with MapperFeature.BLOCK_UNSAFE_POLYMORPHIC_BASE_TYPES enabled, consistent with the mapper used by the component’s JSON data-type transformer. This is defense-in-depth against gadget-chain deserialization: when polymorphic / default typing is enabled, Jackson refuses unsafe base types (such as Object, Serializable or Comparable).

This only affects routes that enable polymorphic / default typing on an unsafe base type; ordinary marshalling and unmarshalling are unchanged. If you rely on that behaviour, supply your own ObjectMapper (via the objectMapper option or the registry) configured without this feature.

The camel-jacksonxml data format now creates its default XmlMapper with MapperFeature.BLOCK_UNSAFE_POLYMORPHIC_BASE_TYPES enabled, mirroring the same hardening applied to camel-jackson. This is defense-in-depth against gadget-chain deserialization: when polymorphic / default typing is enabled, Jackson refuses unsafe base types (such as Object, Serializable or Comparable).

This only affects routes that enable polymorphic / default typing on an unsafe base type; ordinary marshalling and unmarshalling are unchanged. If you rely on that behaviour, supply your own XmlMapper (via the xmlMapper option) configured without this feature.

The camel-jackson-avro and camel-jackson-protobuf data formats now create their default AvroMapper / ProtobufMapper with MapperFeature.BLOCK_UNSAFE_POLYMORPHIC_BASE_TYPES enabled, mirroring the same hardening applied to camel-jackson and camel-jacksonxml. This is defense-in-depth against gadget-chain deserialization: when polymorphic / default typing is enabled, Jackson refuses unsafe base types (such as Object, Serializable or Comparable).

This only affects routes that enable polymorphic / default typing on an unsafe base type; ordinary marshalling and unmarshalling are unchanged. If you rely on that behaviour, supply your own mapper (via the objectMapper option) configured without this feature.

UserProfile token verification now fails closed when no JWK set is available: a signed token can no longer be accepted when the configured JWK set is missing or empty, since its signature cannot be verified in that case. Deployments with a correctly resolved JWK set are unaffected; this aligns the legacy UserProfile path with the JwtTokenValidator SPI path.

When localWorkDirectory is used, the remote-file consumers now ensure the downloaded local work file stays within the configured work directory, so a remote file name containing ../ sequences can no longer resolve to a path outside it. The containment check honours the existing jailStartingDirectory option (default true); set jailStartingDirectory=false to disable it. A remote file that resolves outside the local work directory is rejected with a GenericFileOperationFailedException.

The spring-ws consumer now applies a HeaderFilterStrategy to the SOAP headers it maps onto the Camel Exchange. The default headerFilterStrategy is a new SpringWebserviceHeaderFilterStrategy that filters header names 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-cxf, camel-mail, camel-coap, …​). SOAP header element and attribute names that fall in that namespace are no longer propagated as Exchange headers. Routes that relied on receiving such header names from inbound SOAP headers can supply a custom headerFilterStrategy (via the new headerFilterStrategy endpoint option) to restore the previous behaviour.

The muteException consumer option now defaults to true in camel-netty-http and camel-undertow, aligning these components with the other HTTP server components (camel-http, camel-jetty, camel-servlet, and camel-platform-http), which have been defaulting muteException to true for a long time.

When an exchange fails processing on the consumer side, the HTTP response now has an empty body. Previously the response body contained the exception stack trace as text/plain.

Routes that rely on the exception stack trace being present in the response body must set muteException=false explicitly on the endpoint or component after the upgrade:

Note that muteException takes precedence over transferException, as it already does in the other HTTP server components. Routes using transferException=true on these two components must now also set muteException=false for the serialized exception to be returned in the response.

The KeycloakSecurityPolicy route policy now always verifies the access token when one is present - signature, issuer and expiry for local JWT verification, or active state and issuer when token introspection is enabled - even when neither requiredRoles nor requiredPermissions is configured. Previously the token was only verified when at least one role or permission was required.

Routes that attach a KeycloakSecurityPolicy without any roles or permissions and that previously forwarded an unverified or invalid token will now have such requests rejected with a CamelAuthorizationException. Provide a valid, verifiable token (or configure requiredRoles / requiredPermissions) for these routes.

The camel-whatsapp webhook consumer now supports optional verification of inbound webhook event callbacks via the new webhookSecret endpoint option. When set, event callbacks whose X-Hub-Signature-256 HMAC-SHA256 signature is missing or invalid are rejected with HTTP 403; when the option is not set, behaviour is unchanged.

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

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:

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.

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.

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 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 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 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", …​)).

When using the RETRIEVE_NODES or DELETE_NODE operations with the CamelNeo4jMatchProperties header, the property names provided in the JSON match map are now validated before the MATCH / DELETE WHERE clause is built. Property names must be valid identifiers matching [A-Za-z_][A-Za-z0-9_]*. A request whose match map contains a property name that does not match this pattern now fails fast with an IllegalArgumentException (wrapped in a Neo4jOperationException) instead of producing a malformed query. Property values continue to be passed as bound query parameters and are unaffected.

The SMTP producer no longer extracts dynamic JavaMail session properties from message headers by default. Previously any message header whose key started with mail.smtp. (or mail.smtps.) was applied to a per-message JavaMailSender, which meant an upstream producer that mapped untrusted input into the exchange header map (for example platform-http query parameters, JMS or Kafka messages from untrusted producers) could override transport-security settings such as mail.smtp.ssl.trust or mail.smtp.starttls.enable, or redirect the SMTP connection.

This behaviour is now disabled by default. Routes that legitimately rely on per-message mail.smtp. / mail.smtps. headers must opt back in on the endpoint:

Even with the opt-in, route authors should still strip the namespace with removeHeaders("mail.smtp.", "mail.smtps.") between any untrusted ingress and the mail producer.

In addition, the inbound MailHeaderFilterStrategy now blocks the mail.smtp. / mail.smtps. prefix as well, so an external mail message can no longer inject these into a downstream exchange.

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 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:

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 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 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 Exchange header constants in GoogleCloudFunctionsConstants and GoogleSecretManagerConstants that carried a GoogleCloudFunctions / GoogleSecretManager prefix are not in the Camel namespace and were therefore not filtered by the default HeaderFilterStrategy. 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 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.

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 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", …​)).

Because the three header values are now in the Camel* namespace, transports that filter Camel-internal headers by default (JMS, CXF, HTTP, etc.) will strip the serialized Shiro authentication token before publishing. This is the intended behavior for untrusted producers. Trusted Shiro-over-transport routes that previously relied on the token surviving the boundary must opt those three headers back in via a custom HeaderFilterStrategy, for example:

A worked example is in ShiroOverJmsTest in the camel-itest module.

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 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 Exchange header constants in IrcConstants 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 header(IrcConstants.IRC_SEND_TO) or setHeader(IrcConstants.IRC_TARGET, …​)) continue to work without changes. Routes that set or read the header by its literal string value (for example setHeader("irc.sendTo", …​)) must be updated to use the new value:

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 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 dapr component now ships a default DaprHeaderFilterStrategy (extending DefaultHeaderFilterStrategy) and exposes it via the standard headerFilterStrategy endpoint/component option, aligning the component with the rest of the Camel component catalog (camel-iggy, camel-kafka, camel-jms, …​). The strategy filters headers starting with Camel / camel (case-insensitive) in both directions.

In addition, the dapr-pubsub consumer no longer copies the inbound CloudEvent’s pubsubName and topic into the CamelDaprPubSubName (DaprConstants.PUBSUB_NAME) and CamelDaprTopic (DaprConstants.TOPIC) message headers. These two constants are producer-direction routing headers: they are read back on the producer side by DaprConfigurationOptionsProxy and take precedence over the endpoint-configured pubSubName / topic. Setting them on a consumed exchange caused a route such as

to carry the inbound pubsubName / topic into the producer hop instead of using the configured destination. The remaining CloudEvent metadata headers (CamelDaprID, CamelDaprSource, CamelDaprType, CamelDaprSpecificVersion, CamelDaprDataContentType, CamelDaprBinaryData, CamelDaprTime, CamelDaprTraceParent, CamelDaprTraceState) are unchanged and are still set on the inbound exchange.

Because a dapr-pubsub consumer subscribes to a single, fixed pubSubName / topic, the removed headers were redundant with the endpoint configuration. Routes that relied on reading CamelDaprPubSubName / CamelDaprTopic from a consumed exchange should read the configured destination from the endpoint URI instead.

The Schematron rules-compilation TransformerFactory now runs with secure processing enabled (FEATURE_SECURE_PROCESSING) and with external DTD and external stylesheet access disabled (accessExternalDTD and accessExternalStylesheet set to empty), as defense-in-depth against XXE and external-resource resolution while compiling Schematron rules. This matches the hardening already applied to the component’s SAXParserFactory. The bundled ISO Schematron skeleton stylesheets continue to be resolved from the classpath via the component’s URIResolver and are therefore unaffected.

If your Schematron rules legitimately reference an external DTD, external entity, or external stylesheet, those references will no longer be resolved and rule compilation will fail; inline the referenced content instead.

The camel-test module has been removed from camel-bom. This module was included by mistake, as since Camel 4, this is not a JAR but a pom.xml file. Camel end users should use the camel-test-junit5 / camel-test-junit6 JARs and the others directly.

In the YAML DSL we have renamed routePolicy to routePolicyRef on the route node, as that is the correct name.

In the simple language then init blocks syntax has changed to require that each variable ends with a semicolon and new line (no trailing comments etc is allowed)

For example

Should be changed to have semicolons as shown below:

When configured a custom IdempotentRepository on camel-mail endpoint, then Camel will now auto-start the bean which is similar to what camel-file do as well.

The camel-json-patch is now deprecated - the library it uses is not active maintained and this module does not work with Jackon 3.

When using code first Rest DSL and have configured base.path then this will now be exclusively used for the returned server url in the API specification.

For example here we set base.path=cheese:

Then the generated API specification now returns:

Previously the context-path would always be used:

The intention is to allow to configure the base.path as is in the return API specification.

The simple language has deprecated binary operators that uses space in the name:

The org.apache.camel.component.file.GenericFileOperations has added method storeFileDirectly.

All not working metadata headers have been removed. The option extractAllMetadata has been removed. Using includeRawMetadata will have the same effect given that there is no more customMetadata available.

It corresponds to the removal of functionality no more working since 4.17. Given that this functionality was never available in a LTS version,that the next LST version is the next one and the fix requires important change in upstream dependency; it is not going through a deprecation phase and removed directly.

The class org.apache.camel.component.qdrant.Qdrant.Headers has been removed. It was deprecated since 4.15. It is replaced by org.apache.camel.component.qdrant.QdrantHeaders.

The upgrade of Tahu from 1.0.17 to 1.0.18 introduced an API break. HostApplicationEventHandler has been renamed to MultiHostApplicationEventHandler and introduced one more parameter on all methods.

Even if the interface HostApplicationEventHandler is public, I do not expect Camel users to use the implementation TahuHostApplicationEventHandler from Camel. Also the change would be relatively trivial. So replacing it without deprecating it first in order to be able to use the latest Tahu version right away.

Consequently, there is an API break org.apache.camel.tahu.handlers.TahuHostApplicationEventHandler has been removed. It is replaced by org.apache.camel.tahu.handlers.MultiTahuHostApplicationEventHandler.

When using Rest DSL in contract first style, then the HTTP engine (vertx-web) instead of a single router to handle all incoming Rest API calls, is now one unique router per API endpoint. This change can affect HTTP request validation as vertx/Quarkus is now also performing this per API endpoint according to the API specification.

All together this would make Camel behave similar for Rest DSL for both code first and contract first style.

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 camel-olingo2 and camel-olingo4 component are deprecated. This is due the Apache Olingo project is EOL and has been moved to the attic and is no longer maintained.

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.

UndertowHeaderFilterStrategy now also filters the legacy websocket. Exchange-header prefix (in addition to the Camel / camel* / org.apache.camel.* prefixes it already filtered). This applies to both the in (wire → exchange) and out (exchange → wire) directions and follows the dedicated-filter-strategy shape used by CAMEL-23532 for camel-vertx-websocket / camel-atmosphere-websocket / camel-iggy.

The constants in UndertowConstants (CONNECTION_KEY, CONNECTION_KEY_LIST, SEND_TO_ALL, EVENT_TYPE, EVENT_TYPE_ENUM, CHANNEL, EXCHANGE) keep their existing string values (websocket.connectionKey, websocket.connectionKey.list, websocket.sendToAll, etc.) because they are part of the undertow component’s externally-visible API contract; routes referencing them (symbolically or by literal value) continue to work unchanged within an undertow route.

The behaviour change applies at undertow’s transport boundary:

Note that the HeaderFilterStrategy only governs the transport boundary; it does not prevent cross-component header injection (for example, an http → undertow route where the HTTP consumer maps an attacker-supplied websocket.connectionKey header into the exchange and the undertow producer then reads it via in.getHeader(…​) to dispatch to a specific peer). For defence in depth at the trust boundary, route authors should explicitly strip these headers from untrusted inbound traffic, for example:

Routes that intentionally relied on undertow mapping websocket.* wire headers in or out can supply a custom headerFilterStrategy endpoint option to restore the previous behaviour.

UndertowEndpoint defaulted its headerFilterStrategy to the base HttpHeaderFilterStrategy, and pushed that strategy into the DefaultUndertowHttpBinding it creates lazily, overwriting the UndertowHeaderFilterStrategy that the binding installs in its own constructor. The undertow-specific filtering was therefore not applied on endpoint-configured routes.

The endpoint now defaults to UndertowHeaderFilterStrategy, which makes two already documented behaviours take effect:

Ordinary application headers are unaffected, and Rest DSL consumers already used an undertow-specific strategy (UndertowRestHeaderFilterStrategy) so their behaviour does not change. Routes that relied on websocket.* headers crossing the undertow boundary in either direction, and routes that relied on undertow-invalid header names being mapped, can restore the previous behaviour by configuring headerFilterStrategy explicitly on the endpoint:

Routes that already supply a custom headerFilterStrategy or a custom undertowHttpBinding are unaffected.

Sqs2HeaderFilterStrategy now also configures an inbound filter aligned with the existing outbound regex. Headers starting with Camel / camel (case-insensitive), breadcrumbId and org.apache.camel.* are now filtered 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 receiving these header names from inbound SQS messages can supply a custom headerFilterStrategy to restore the previous behaviour.

Sns2HeaderFilterStrategy now also configures an inbound filter aligned with the existing outbound regex. Headers starting with Camel / camel (case-insensitive), breadcrumbId and org.apache.camel.* are now filtered in both the inbound and outbound directions, aligning the component with the rest of the Camel component catalog. Routes that relied on receiving these header names on inbound SNS messages can supply a custom headerFilterStrategy to restore the previous behaviour.

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 Exchange header constants in KafkaConstants used header values in the lowercase / dotted kafka.* namespace, outside the Camel namespace, and were therefore not filtered by the default HeaderFilterStrategy on upstream HTTP / REST consumers. They 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:

KafkaConstants.MANUAL_COMMIT was already Camel-prefixed (CamelKafkaManualCommit) and is unchanged.

Routes that reference the constants symbolically (for example setHeader(KafkaConstants.OVERRIDE_TOPIC, …​)) continue to work without changes. Routes that set or read the headers by their literal string values (for example setHeader("kafka.OVERRIDE_TOPIC", …​) or Simple expressions such as ${headers[kafka.TOPIC]}) must be updated to use the new values:

The generated Endpoint DSL header accessors on KafkaEndpointBuilderFactory keep their method names (kafkaOverrideTopic(), kafkaTopic(), kafkaPartitionKey(), …​); only the returned string value reflects the new CamelKafka* convention.

The Exchange header constants in SalesforceEndpointConfig have been renamed to follow the Camel naming convention used across the rest of the component catalog, so that they are governed by the default HeaderFilterStrategy (which only filters Camel/camel-prefixed headers). The Java field names are unchanged; only the header string values have changed.

These parameters are dual-use: they can be supplied either as endpoint options (for example salesforce:query?sObjectQuery=…​) or as message headers. The endpoint option spelling is unchanged — only the header name has changed.

Routes that reference the constants symbolically (for example setHeader(SalesforceEndpointConfig.SOBJECT_QUERY, …​)) continue to work without changes. Routes that set the value as a header by its literal string (for example setHeader("sObjectQuery", …​)) must be updated to the new value (setHeader("CamelSalesforceSObjectQuery", …​)), or preferably switch to the symbolic constant. The apexQueryParam. header prefix is likewise renamed to CamelSalesforceApexQueryParam., so a header such as apexQueryParam.foo must now be set as CamelSalesforceApexQueryParam.foo.

The configuration-only options that are never read from a message header — apiVersion, format, rawPayload, defaultReplayId, fallBackReplayId, initialReplayIdMap, replayPreset, pubSubDeserializeType, pubSubPojoClass, notFoundBehaviour and fallbackToLatestReplayId — are unchanged, as is the Approval API approval / approval.<property> mechanism (whose endpoint-option and header spellings are intentionally identical and bound to the approval endpoint parameter name).

The key lifecycle managers now store key metadata as JSON instead of using Java serialization. AwsSecretsManagerKeyLifecycleManager and HashicorpVaultKeyLifecycleManager previously stored the KeyMetadata as a Base64-encoded, Java-serialized value; they now store it as JSON, consistent with FileBasedKeyLifecycleManager. Metadata written by previous versions is still read transparently and is migrated to JSON the next time the metadata is updated.

Because older versions cannot read the new JSON metadata, downgrading after new key metadata has been written is not supported.

When fileDir is configured, the Azure Storage Blob and DataLake consumers now ensure the downloaded local file stays within the configured directory, so a remote object name containing ../ sequences can no longer resolve to a path outside it. This is consistent with the containment already performed by the file-based consumers.

Ordinary object names are unaffected. A name that resolves outside fileDir is now rejected with an IllegalArgumentException.

When the consumer is configured with downloadFileName pointing at a directory, the remote object name is appended to that directory to build the local file to write. The resolved path is now verified to stay within the configured directory, and an IllegalArgumentException is thrown if it does not.

Object names are still allowed to contain / and are mapped to sub-directories of the download directory as before, so nested object names keep working unchanged. Only names that resolve outside the configured directory are rejected.

If downloadFileName is configured with an expression (i.e. it contains $), the local path is built by that expression as before and is not subject to this check.