Apache Camel 4.x Upgrade Guide

Required tool arguments whose names start with camel or org.apache.camel. (case-insensitive) now reject the invocation before the tool route runs. Previously, these arguments could pass the required-argument check and then be discarded by the reserved-name filter, leaving the route without a required value. Rename these parameters and update their parameter.* or argSchema declarations.

Breaking change: Camel 4.24 requires Java 21 as the minimum runtime version. Java 17 is no longer supported. Upgrade your JDK to 21 or later before upgrading to Camel 4.24.

When scanning classes in a package (for example camel.main.base-package-scan=com.acme.routes, or PackageScanClassResolver.findImplementations), classes found in a JAR were also included when they belonged to a sibling package whose name merely started with the scanned package name, such as com.acme.routesupport or com.acme.routes2. Scanning a directory on the classpath never did this. Both now only include the scanned package and its sub packages, so a RoutesBuilder or @Configuration class in such a sibling package is no longer discovered when running from a JAR; list that package explicitly if it should be scanned.

The Route.clearRouteModel() method is deprecated and is now a no-op. It will be removed in a later release.

This method dropped the references a runtime route held to its model (the route definition, the error handler factory and the error handlers) once the route was created at startup. The CamelContext already keeps the route definitions in its model, so clearing them on the route saved little memory at the cost of making Route.getRoute() and Route.getErrorHandlerFactory() return null for routes created at startup (but not for routes added after startup).

Applications that called Route.clearRouteModel() directly can remove the call. Implementations of the Route interface that override clearRouteModel() can remove the override.

The skipBindingOnErrorCode option of the Rest DSL (on restConfiguration, rest, its verbs and restBinding) is now documented with the default value true, the default it has always had at runtime. Before, the model, the catalog, the XML and YAML DSL schemas said false. Routes behave as before.

Tools that read the default from the catalog or the schemas now see true.

When pollEnrich (or poll) times out and no aggregationStrategy is configured, the body is set to null, and with variableReceive the variable is null. For a message that creates its body on demand, the null did not stick: the next read created the body again. The message of a file consumer creates its body from its file, so after a timeout the body, or the variable of variableReceive, was the file of the incoming exchange instead of null. The messages of the JMS, sjms, mail, HTTP, XMPP, SMPP, SNMP and Spring WS consumers create their body on demand as well, so there it was the payload of the consumer again.

The body, or the variable, is now null after a timeout for these consumers too. A route that read the incoming file or payload from the body after a timed out pollEnrich must keep it before the pollEnrich instead, for example with variableReceive, which leaves the body as it was. To keep the body empty, the message is replaced by a plain message with the same message id, headers and attachments, so after a timeout it is no longer of the message type of the consumer (such as GenericFileMessage or JmsMessage).

A Camel Main application that fails to start now logs why, at ERROR: Error starting Camel: …​ with the stack trace, as camel run already did. Before, the failure left main() and only the JVM printed it, on stderr (Exception in thread "main" …​), so the log file of the application did not say why it stopped. The JVM no longer prints that same failure a second time. When the application logs nothing at ERROR (such as without a logging implementation), the JVM prints it as before.

The catalog now accepts all camel. groups defined in camel-main-configuration-metadata.json (previously only 7 of the 36 groups were recognized, besides camel.component., camel.dataformat. and camel.language.). As a result, camel-report-maven-plugin:validate and the camel-jbang MCP camel_configuration_validate tool now validate 29 additional camel. groups (including camel.server., camel.management., camel.vault., camel.ssl.*, and others).

If your project uses Spring Boot and has options such as camel.metrics.uriTagEnabled (from a Camel starter) that are not in the camel-main schema, camel-report-maven-plugin:validate may report them as "Unknown option", which fails the build when failOnError=true. The camel_configuration_validate MCP tool with runtime=spring-boot reports such keys as checked=false instead.

Group names are now matched with dash- and case-insensitive normalisation, matching how camel-main binds keys at runtime. For example, camel.error-registry.enabled and camel.ai-observability.enabled are now accepted alongside their camel-case equivalents.

If your project uses camel-report-maven-plugin:validate with failOnError=true, a key that was silently ignored before (e.g. a misspelled option under one of the newly accepted groups) may now cause the build to fail. Review the validation output and correct any misspelled keys.

The camel_configuration_validate MCP tool response format has changed:

If you call camel_configuration_validate programmatically and read the JSON response, update field references from accepted to checked and handle the new summary.unchecked field.

TypeSafe AI Semantic applications must add org.apache.camel:camel-semantic-typesafe-ai. The camel-typesafe-ai component and TypeSafe AI language remain independently usable and no longer bring in camel-semantic. The new expert artifact includes both dependencies transitively. Existing bean declarations and imports for org.apache.camel.component.typesafeai.TypeSafeAiSemanticAdapter remain valid.

Spring Boot applications using this expert must keep camel-typesafe-ai-starter and add org.apache.camel:camel-semantic-typesafe-ai at the matching Camel version. The existing starter continues configuring the component and TypeSafe AI language; register the Semantic expert explicitly as a named Spring bean. Applications using only the component or TypeSafe AI language need no new dependency.

Replace org.apache.camel:camel-wolf-defender with org.apache.camel:camel-semantic-wolf-defender. The Wolf Defender Java packages, classes, model provisioning and configuration properties are unchanged. Its documentation page is now semantic-wolf-defender.adoc.

Update Maven dependencies and Camel JBang --dep options to the new expert artifact names. Each Semantic evaluation still selects an explicit named registry expert. Provider identities and operation names remain typesafe-ai and wolf-defender; only the reported adapter artifact changes.

TypeSafe AI now rejects explicit media parts nested in structured input, instructions or criteria, which previously could be serialized and sent to the provider. Text and JSON-compatible Map/List state remain supported. Binary objects and image, audio or video parts are rejected before HTTP; plain text and ordinary application field names do not imply media. Records such as {type: image, url: …​, sku: 42} and MIME metadata with a URL alone remain application state. Direct Semantic adapter calls and batches use the same validation. Wolf Defender remains text-only with its existing limits.

Every evaluation in the preview semantic API now requires an explicit expert registry bean name. Move block-level expert values onto each evaluation in YAML and XML; in Java, move .expert(…​) from SemanticEvaluationsBuilder to each SemanticEvaluationBuilder.

The camel.language.semantic.default-expert and camel.language.semantic.adapter options, SemanticLanguage.setDefaultExpert / setAdapter, automatic selection of a sole expert, and META-INF/services/org/apache/camel/semantic-adapter discovery are removed. Register an expert bean explicitly, including its initialization and destruction methods where needed, and reference it from each evaluation. Expert references accept property placeholders, but do not fall back to class loading. The default state selector is unchanged.

The semantic metadata response no longer includes defaultExpert, defaultError or defaultErrorCode. Operation inspection and completion require an explicit expert reference.

The preview semantic audit API no longer records route actions. SemanticAuditDecision, SemanticAudit.get(context).decision(…​) and SemanticObserver.decision(…​) have been removed. Remove the corresponding decision beans and processor calls from routes. Evaluation auditing is automatic under the existing audit configuration; normal application routing remains unchanged. Previously persisted version-1 decision records remain readable and exportable as legacy data. Semantic audit browsing no longer accepts route-action, namespace or application-correlation filters. The console’s target filter is also removed. Newly captured evaluation records use definition instead of target; update consumers and queries to read definition. Previously persisted records retain their original fields. Event-ID detail responses no longer expand a decision’s evidence references automatically; use caseEventId for a bounded associated case or eventIds for explicit bulk retrieval. The original persisted record remains available in record. Use automatic evaluation provenance, including entry/executing route and Camel breadcrumb identifiers. The internal CamelSemanticAuditReferences exchange property is no longer populated. In audit health responses, capturing replaces decisionsEnabled; it indicates that some expert enables evaluation capture. For external readers, retained is unknown instead of a count from the unrelated memory store.

SemanticAuditReader.getAll no longer imposes a 100-ID evidence limit. Callers must bound requests and responses; backend implementations may split retrieval into their own batches. The 100-reference limit on legacy persisted evidence records remains unchanged.

Camel now uses Vert.x 5. This affects camel-vertx, camel-vertx-http, camel-vertx-websocket, camel-platform-http-vertx, camel-platform-http-main, camel-platform-http-jolokia, camel-knative-http and camel-oauth. Application code that uses the Vert.x API directly, for example to create a custom Vertx instance, a custom Router handler, or an authentication provider for platform-http, must be migrated as described in the Vert.x 5 migration guide. Notably, the callback variants of asynchronous methods are removed in favour of the methods returning a Future.

A metrics or tracing factory can no longer be set on the VertxOptions given to a component (the MetricsOptions.setFactory and TracingOptions.setFactory methods are removed). Either create the Vertx instance with Vertx.builder() and set it on the component (or bind it to the registry), or register the factory as a io.vertx.core.spi.VertxServiceProvider service.

VertxPlatformHttpRouter.mountSubRouter is removed, as it is no longer part of the Vert.x Router API. Use router.route(mountPoint + "*").subRouter(subRouter) instead.

When the connection of a WebSocket is lost without a close frame, the camel-vertx-websocket consumer no longer passes the resulting exception to the consumer exception handler, and no longer routes it as an ERROR event. It is handled as a WebSocket closed with a close frame: a consumer with fireWebSocketConnectionEvents=true routes a CLOSE event, and a consumer with consumeAsClient=true reconnects. With the default fireWebSocketConnectionEvents=false, the lost connection of a peer is therefore no longer logged as a warning.

When the WebSocket of a consumer with consumeAsClient=true reports any other error, the consumer exception handler now receives that exception. Previously it received the cause of that exception, which could be null.

When the WebSocket that the camel-vertx-websocket producer sends to (a server not managed by Camel) reports an error other than a lost connection, the exchange now fails with that exception. Previously it failed with the cause of that exception, which could be null.

camel-arangodb still uses Vert.x 4, as the ArangoDB Java driver does not support Vert.x 5 yet (see arangodb-java-driver#625). An application that uses camel-arangodb together with one of the components above resolves a single version of the io.vertx artifacts, so either the ArangoDB driver or the other components fail at runtime. The workaround suggested by the driver maintainers is to replace com.arangodb:arangodb-java-driver with com.arangodb:arangodb-java-driver-shaded, which embeds its own relocated copy of Vert.x. The vertx option of camel-arangodb cannot be used in that case.

camel-kubernetes now uses the fabric8 Kubernetes client 8.0, which brings these changes for applications:

See the Kubernetes client 8 migration guide for the other changes.

Each aws2-kinesis endpoint now uses the Kinesis client of its own configuration (region, credentials, uriEndpointOverride, or amazonKinesisClient / amazonKinesisAsyncClient). Before, all endpoints of the component used the client of the endpoint that started first, and stopping one endpoint (for example by removing its route) closed that client for every other endpoint.

Camel now closes only the clients it created. A client set with amazonKinesisClient or amazonKinesisAsyncClient, on the component or on an endpoint, is no longer closed when Camel stops: close it yourself when you no longer need it.

The Gson and JSON-B data formats now use the CamelGsonUnmarshalType and CamelJsonbUnmarshallType headers to choose the class to unmarshal to only when the new allowUnmarshallType option is enabled, as the Jackson data formats do with CamelJacksonUnmarshalType. By default the headers are ignored, and the configured unmarshalType is used (a Map for a JSON object when none is configured). A route that sets the header must enable the option, for example with .unmarshal(new JsonDataFormat(JsonLibrary.Gson).allowUnmarshallType(true)) or <json library="Gson" allowUnmarshallType="true"/>.

The google-mail, google-mail-stream, google-drive, google-calendar, google-calendar-stream, google-sheets and google-sheets-stream components now create one API client per endpoint, from the options of that endpoint (clientId, clientSecret, refreshToken, accessToken, serviceAccountKey, delegate, scopes and applicationName, plus emailAddress, p12FileName and user on the two calendar components), instead of a single client per component that every endpoint of the component shared. Each endpoint keeps its client for its lifetime. The clientFactory option of a google-drive endpoint is now used to create the client of that endpoint. In addition, a google-mail-stream endpoint configured with neither clientSecret nor serviceAccountKey now fails with an IllegalArgumentException when its client is created, instead of getting a null client and failing at the first API call. The google-mail:update-message-labels data type transformer now uses a client created from the component-level configuration (the camel.component.google-mail.* options), kept until the component stops. Before, it used whichever client the component had already created, for example the one of a google-mail:messages/modify endpoint, so credentials set only on an endpoint URI no longer reach the transformer: set them on the component as well.

camel validate source and camel overview now use the same rules for a direct:, seda: or disruptor: endpoint that a route sends to and no route consumes, so they report the same endpoints on the same project:

So camel validate can report an endpoint it did not report before.

Since 4.18 the producers of the remote file components (ftp, ftps, sftp, mina-sftp, scp, smb, azure-files) accepted checksumFileAlgorithm but wrote no checksum file and did not set the CamelFileChecksum header; when an earlier file producer of the route had set that header, they wrote its checksum, the checksum of another payload. They now calculate the checksum of the bytes they upload, write the checksum file (unless checksumWriteFile=false) and set the header, as in 4.14. A checksum header set before the producer is no longer used by any file producer. scp and azure-files upload the bytes of the body without the charset option, while the checksum applies it: do not set charset with checksumFileAlgorithm there. FTP uploads in ASCII mode unless binary=true, and the server may then change the line ends of the stored file, so its checksum can differ from the checksum of the uploaded bytes.

A done file with a fixed name (such as doneFileName=ready) is no longer deleted while a poll left files of its directory for the next poll (beyond maxMessagesPerPoll, or not started); before, they were left until a new done file was written. Meanwhile the polls consume every file of the directory, as they do whenever the done file is there. This also applies to pollEnrich and ConsumerTemplate.receive, which take one file per call: the done file is now kept until the last file of the directory is received, where before the first received file deleted it. This applies to camel-ftp, camel-sftp, camel-smb and camel-azure-files as well.

poll and pollEnrich with a file based component (file, ftp, ftps, sftp, smb and azure-files) evaluate a dynamic fileName that does not use the file functions on the current message, so fileName=${body} and fileName=${body[customer]}.json read its body. Before, the consumer evaluated it for each file found, with that file as the body, so ${body} was the file found. A fileName that uses the file functions (${file:…​}, ${date:file:…​}) is still evaluated for each file found, and headers, variables and exchange properties work as before. A fileName that read the file found through its headers, such as ${header.CamelFileName}, must use the file functions instead (${file:name}).

The four remaining Exchange header constants of SwiftConstants have been renamed to follow the Camel naming convention used by the rest of the component, completing the rename done in 4.21. The Java field names are unchanged; only the header string values have changed.

The previous values were kept in 4.21 on the understanding that they were part of the Swift HTTP contract. They are not: the container producer passes the values to the openstack4j CreateUpdateContainerOptions, which builds the X-Container-Meta-, X-Versions-Location, X-Container-Read and X-Container-Write names of the Swift request itself. The request Camel sends to Swift is therefore unchanged by this rename.

Routes that reference the constants symbolically (for example setHeader(SwiftConstants.CONTAINER_READ, …​)) continue to work without changes. Routes that set one of these headers by its literal string value (for example setHeader("X-Container-Read", …​) in an XML or YAML route) must be updated to the new value (setHeader("CamelOpenstackSwiftContainerRead", …​)); the previous names are no longer read.

The generated Endpoint DSL header accessors on the Swift HeaderNameBuilder are renamed accordingly (xContainerMeta() → openstackSwiftContainerMetadata(), xVersionsLocation() → openstackSwiftVersionsLocation(), xContainerRead() → openstackSwiftContainerRead(), xContainerWrite() → openstackSwiftContainerWrite()).

With checksumFileAlgorithm, the file producer calculated the checksum from the body before it was written. With charset set, it also decoded that body with the default charset of the JVM instead of the charset of the exchange. So with charset, the checksum (the CamelFileChecksum header and the checksum file) did not match the written file as soon as the encoding changed a byte, a body read with another charset (such as the bytes of a file consumed with charset=ISO-8859-1) was written with its non-ASCII characters replaced, and a String body could fail with an UnmappableCharacterException; with fileExist=Append and appendChars, the checksum left out the appended characters. The checksum is now calculated from the bytes written to the file, and the body is decoded as it is without checksumFileAlgorithm. Checksums of such files differ from the ones written before.

The hybrid KEM operations now fail with an IllegalArgumentException when hybridKdfAlgorithm is not one of HKDF-SHA256, HKDF-SHA384 or HKDF-SHA512. Before, any other value silently fell back to HKDF-SHA256, so a typo such as HKDF-SHA-512 went unnoticed - and if only one end of an exchange carried the typo, both ends still reported success while deriving the key with different digests.

The HKDF info bytes of the hybrid KEM are also now encoded explicitly as UTF-8, where they previously used the platform default charset. The info string is the symmetric algorithm name, so this has no effect for the usual values such as AES, which are pure ASCII. A deployment running on a JVM whose default charset cannot encode that name identically to UTF-8 would, however, derive a different key than the previous version, and could not decrypt material produced by it.

Stopping a pqc endpoint no longer removes the BC and BCPQC providers from java.security.Security.

java.security.Security is JVM-global, and the endpoint only added a provider when it was absent, so stopping one endpoint could remove a provider it had not installed - breaking the other pqc endpoint of the same route, other CamelContext instances, components such as camel-crypto, camel-ssh and camel-xmlsecurity, and any non-Camel code in the same JVM.

An application that relied on the providers being de-registered on shutdown must now remove them itself with Security.removeProvider("BC") and Security.removeProvider("BCPQC").

camel validate normalize <files> --output=<dir> now writes one normalized file per input file into the directory, with the name of the input file, instead of merging all the routes into normalized.yaml. A top-level onException of a file then keeps applying to the routes of that file only, as it does in the source. This applies to a single input file too: camel validate normalize orders.yaml --output=out/ now writes out/orders.yaml instead of out/normalized.yaml. normalized.yaml is only written for what was not loaded from one of the input files. Input files with the same name in different directories are written as <parent directory>-<name>. Scripts that read <dir>/normalized.yaml must read the per-file outputs instead.

The command now refuses to write over one of its input files (for example --output=. in the directory of the routes) and exits with an error.

With --output=<file> or without --output, the routes are still merged, and the command now warns, on the standard error, when the top-level onException of one file applies to the routes of the other files in the merged output.

The SecretKeyWithEncapsulation produced by generateSecretKeyEncapsulation now carries the mapped JCE algorithm name, as the extractSecretKeyEncapsulation and extractSecretKeyFromEncapsulation operations already did. Before, it carried the raw enum name.

This is only visible for the two algorithms whose enum name differs from the JCE name: DESEDE now yields DESede (was DESEDE), and GOST3412_2015 now yields GOST3412-2015 (was GOST3412_2015). The raw names are not resolvable cipher algorithms, so a key labelled with one could not be passed to Cipher.getInstance(key.getAlgorithm()), and the generate and extract ends of the same exchange disagreed on the key’s identity. Code asserting on the old value must be updated.

generateSecretKeyEncapsulation now also rejects a missing symmetricKeyAlgorithm with Symmetric Algorithm needs to be specified, as the extract operations already did, instead of failing later inside BouncyCastle with Missing argument.

camel ask now asks on the terminal before a file write (showing the diff), a message to an endpoint the integration does not have, SQL that changes data, an expression in a language that runs code, stopping or restarting the integration, and a camel command that changes something. Without a terminal to ask on, as in a script, such a call does not run: pass --yes to let it run without asking.

The model gets the shared file tools (camel_get_files, camel_edit_file, camel_write_file), which validate what they write, instead of the read_file, list_files and write_file tools of camel ask. A local model gets a core set of tools (--tools=auto, the default), a hosted model the full set. The default of --max-iterations is now 25 instead of 10, and --model llama3.2 now selects that model also when a model better at tool calling, such as qwen3.6, is installed.

Two of the three documented rotation signals of KeyRotationScheduler previously never triggered. Both now work, so a deployment that already configured them will start rotating keys where before nothing happened.

Review any configured maxKeyUsage threshold before upgrading: a long-running deployment may rotate on the first check once the counter starts advancing.

Recording the usage also costs a write. A signing endpoint with a keyLifecycleManager and a CamelPQCKeyId header now updates the key metadata in the backing store on every signature, where a non-stateful key previously wrote nothing. Against AWS Secrets Manager, Azure Key Vault or HashiCorp Vault that is a remote call per message. A failure to read or write that metadata does not fail the exchange for a non-stateful key - it is logged once per producer and the signature is returned - because losing a usage count only delays a rotation. Leave the CamelPQCKeyId header off the signing exchanges, or use maxKeyAge or nextRotationAt, if the write is not wanted.

The key encapsulation operations do not record usage, so maxKeyUsage still never triggers for a KEM key.

Signing with one of the stateful hash-based algorithms (LMS, HSS, XMSS, XMSSMT) consumes a one-time index inside the private key. That advanced key is now persisted through the keyLifecycleManager before the signature is placed on the message, instead of after.

Such an exchange already failed when the key state could not be stored, so what changes is the content of the failed message: it no longer carries CamelPQCSignature, nor the hybrid CamelPQCHybridSignature, CamelPQCClassicalSignature and CamelPQCPqcSignature headers. A route that caught the failure with onException(…​).handled(true), or routed it to a dead letter channel, could previously read the signature off the failed message and pass it on; it can no longer do so. That is the point of the change - a signature whose index advance was never recorded must not escape, because after a restart the key resumes at the previous index and can sign a second time with an index already used.

Signing a stateful key without a keyLifecycleManager, and signing any key without a CamelPQCKeyId header or with no stored metadata for the key, now logs a warning once per producer rather than being silently ignored. A non-stateful key without a keyLifecycleManager stays silent, as there is no maxKeyUsage threshold to miss. For a stateful key the warning names the index-reuse risk; for any other key it names the usageCount that will not advance.

camel get endpoint replaces the REMOTE column with SCOPE, which tells three kinds of endpoint apart: remote (an external system, as before), internal (Camel plumbing that stays inside the integration, such as direct, seda or log, as the catalog marks its component internal) and local (neither, such as exec or bean). Scripts that read the REMOTE column of the table must read SCOPE instead. The --json output keeps remote and adds internal.

A CamelPQCOperation header selecting an operation the endpoint holds no key material for is now rejected with an IllegalArgumentException naming the requested operation, the configured one, and what is missing. Before, an override crossing between the signature and the key encapsulation operations dereferenced a null and surfaced as a bare NullPointerException. Routes relying on such an override have to configure a separate endpoint for the other operation; the override itself keeps working within a family and for the operations that need no key material.

Two header declarations also carried the wrong javaType in the component metadata, which is visible to tooling and in the generated header table. CamelPQCOperation is org.apache.camel.component.pqc.PQCOperations (was String) and CamelPQCSecretKey is javax.crypto.SecretKey (was Boolean). The runtime values are unchanged - only the declared types were wrong.

All commands find running integrations the same way:

Four differences between the KeyLifecycleManager implementations are resolved. All four are corrections, but each is observable.

PEM handling is also now explicitly UTF-8 rather than the platform default charset.

The Camel CLI has a documented set of exit codes (see Exit Codes and Output): 0 success, 1 failed, 2 usage error, 3 not found, 70 internal error and 124 timed out. A script that checks the exit code of a command must take these changes into account:

Errors, warnings and tips are printed on stderr instead of stdout, so stdout only has the output of the command, such as JSON. If a script reads the error text of a command from stdout, read stderr instead. The list of plugins that are not installed, after camel --help, is printed on stderr, and only in an interactive terminal.

parameterSpec can now select a named parameter set for MAYO and SNOVA. Both were rejected on the grounds that they have no name-addressable BouncyCastle parameter spec, which is not the case: MayoParameterSpec.fromName and SnovaParameterSpec.fromName both exist, and neither algorithm is stateful. The stateful hash-based signatures (XMSS, XMSSMT, LMS, HSS) are still rejected, as they genuinely have no such spec.

DILITHIUM and SPHINCSPLUS no longer produce the "not part of NIST FIPS 204/205" warning on hybrid endpoints. Both are aliases that resolve to ML-DSA and SLH-DSA, so the warning was recommending the algorithm already in use. FALCON, MAYO, SNOVA, XMSS and XMSSMT still warn.

The five default key material classes that generated their key pair with the provider’s default RNG (Falcon, MAYO, SNOVA, LMS, HSS) now use the shared SecureRandomHelper like the other sixteen. No key format or parameter set changes; only the randomness source is now uniform.

An action written to ~/.camel/<pid>-action-<requestId>.json now always gets an answer in ~/.camel/<pid>-output-<requestId>.json, so a tool no longer waits for its timeout:

The WebSocket transport adds the same reason to its result frame. The shared ~/.camel/<pid>-action.json used by older Camel CLI versions is unchanged. A tool built on the file transport that relied on actions without a result writing nothing, or that waited for a timeout, sees these answers now. The Camel MCP route tools, for example, now report a route stop as done instead of a timeout.

With --json, stdout is exactly one JSON document, also when the command fails, so a script or an AI agent can parse it (see JSON output):

New --json options: camel doctor (the status OK, WARN or FAIL of each check), camel validate yaml, camel validate properties and camel validate source (valid, file and errors of each file, as the MCP tool camel_validate_source answers), camel doc (the documentation the MCP tool camel_catalog_doc gives), camel config get, camel config list, camel plugin get and camel plugin list.

The commands that act on a running integration now report how the action went in their exit code (see Exit Codes and Output):

The commands that wait for the integration have a --timeout option, and the ones that return data have a --json option: camel cmd thread-dump, heap-histogram, heap-dump, browse, span, stub, sql, logger, route-dump, camel get bean, source, route-controller, startup-recorder, camel top source and camel trace (the status of tracing). camel get history --json prints one JSON array instead of one document per line.

The JSON of the listings (--json) changes, so that a script can use the values without parsing text:

camel cmd browse --endpoint with an endpoint that the integration cannot browse, or that it does not have, exits with 3 (it printed an empty table and exited with 0).

Without an interactive terminal, such as in a script, a CI job (the CI environment variable is set) or an AI agent:

--follow and --open-url without a value turn the option on. As boolean options that are on by default, they turned it off (use --follow=false to turn it off). In a terminal, the end of the input (Ctrl+D) stops a command that watches or follows, like Enter does.

camel ask, camel explain and camel overview --ai fail when the LLM given with --url does not answer: they went on to another provider, such as the Ollama of the host, or a hosted provider with an API key in the environment, and sent the prompts there. The AI panel of the Camel TUI does the same with the URL of its settings. Without --url the provider is detected as before.

The XML, YAML and Java route dumps (camel transform route, camel validate normalize, camel.main.dumpRoutes, the developer console) now write these options whenever they are set, also with their documented default value: the binding options of the rest configuration, a rest and its verbs (such as bindingMode="off"), the options of a redelivery policy, of a resilience4jConfiguration and of a faultToleranceConfiguration, shutdownRoute / shutdownRunningTask of a route, and apiDocs of a rest verb. Left out, such an option took the value of the parent level when the dump was loaded (the rest configuration or the rest, the error handler, the global circuit breaker configuration, the CamelContext), so the route behaved differently, or, for apiDocs, a verb with apiDocs="true" under a rest with apiDocs="false" was left out of the OpenAPI document.

A boolean option that is on by default is now on when it is given without a value, like any other boolean option: camel export --maven-wrapper exports the Maven wrapper, camel config set --global key=value writes the global configuration, camel cmd receive --show-body shows the body, and camel kubernetes run --dev --cleanup removes the deployment when it stops. Such a flag turned the option off before (picocli sets a flag to the opposite of its default). Turn the option off with =false, such as --maven-wrapper=false, which works as before.

The commands that sort their rows by --sort, such as camel ps, camel get route, camel cmd thread-dump or camel catalog component, exit with 2 and list their keys when the key is unknown: camel ps --sort=nmae printed the integrations unsorted. A row without the value of the key now comes first, instead of failing the command.

camel catalog kamelet --filter no longer fails with an internal error (70) when a Kamelet has no description. An unknown --type exits with 2 (it showed nothing), a --filter that matches nothing says so on stderr, and --json prints the Kamelets as JSON, as the other camel catalog commands do.

camel init exits with 1 when the file it creates exists already, and leaves the file as it is (it overwrote the file before). Use --force to overwrite it. The same holds for the files camel init downloads from GitHub or a gist, of which it writes none when one of them exists. When the template is picked in the terminal (camel init without a file), the command asks there whether to overwrite the file.

CamelCommand.getActionFile and CamelCommand.getOutputFile, the action and output files that all the clients of an integration share, are deprecated. A plugin command sends an action with ActionClient instead, which gives each action a file of its own, so that two clients cannot overwrite each other’s action or answer, and uses the shared files only for an integration before Camel 4.21. camel debug sends its commands this way too.

camel cmd eval, and the tools that evaluate an expression in a running integration (camel ask, and camel_eval_expression of camel mcp and camel tui --mcp with an integration selected), send the expression and the body as they are. They escaped them, which the integration does not undo: an expression with a double quote failed, such as ${body} == "hello", and a slash (as in every XPath) or a quote in the body became part of the text.

The camel_migration_compatibility tool no longer takes the camelComponents argument, which it never used. It now takes the Java requirement from the JDK versions of the target release in the catalog (the same data as camel_version_list): Camel 4.19 and later no longer report Java 17 as a blocker, and javaCompatibility also lists the supportedVersions. A target version newer than every release in the catalog has no Java requirement: the tool says so in warnings instead of taking the one of the newest release.

camel_migration_recipes returns commands that run: the Spring Boot command activates org.apache.camel.upgrade.CamelSpringBootMigrationRecipe, the recipes artifact is the <major>.<minor>.0 release of the target version, the OpenRewrite plugin is no longer pinned to a version, and the Quarkus command runs the quarkus-maven-plugin at the Quarkus platform version of the new optional quarkusPlatformVersion argument (or the latest one), with -Drewrite=true for a full run.

In camel_dependency_check and camel_dependency_security_audit the dependencies are the declared ones: a component only in dependencyManagement or in the dependencies of a plugin no longer counts, and Spring Boot starters and Camel Quarkus extensions count as the component they provide. The version status of camel_dependency_check compares the project with the latest Camel release, added as latestVersion, instead of the catalog version of the server. The security audit no longer audits the server’s catalog version when the pom.xml sets no Camel version: it audits the camelVersion argument, else lists every advisory of the declared components, and says so in warnings. Its reachable is null when no routes are given, advisories without components are returned as uncheckedAdvisories, and clean is true only when none of them apply.

The camel_openapi_mock_guidance MCP tool is removed. Call camel_openapi_scaffold with missingOperation=mock instead: its answer explains the mode and lists the camel-mock/ files, one per path of the spec. The scaffold and camel_openapi_validate now follow the rules of camel-rest-openapi: an operation without operationId is routed to direct:GENOPID_<METHOD><path> with / replaced by . and the braces of path parameters by (direct:GENOPID_GET.pets._petId for GET /pets/{petId}), and a mock file has the request path as its name, without the HTTP method (camel-mock/pets/42.json for GET /pets/42). The security scheme diagnostics of camel_openapi_validate are now all warnings with a SECURITY_<type> code (SECURITY_APIKEY, SECURITY_HTTP, …​), as camel-rest-openapi enforces none of them, and OPENAPI_31 is reported as information instead of a warning.

When a route marks the exchange rollback only (for example with markRollbackOnly() or markRollbackOnlyLast()) there is no exception on the exchange, and these consumers treated it as a success. The JPA consumer deleted the entity (or called its @Consumed method) and committed the poll, and the transacted (transacted=true) Hazelcast SEDA consumer committed its transaction, so the message was removed from the queue. Now a rollback only exchange is not consumed: the JPA consumer leaves the entity in the table, so the next poll consumes it again, as long as it still matches the query. With transacted=false the other entities of the poll are still consumed (without logging a WARN), and so is what a @PreConsumed method changed before routing; with transacted=true the whole poll is rolled back, as for a failed exchange. The Hazelcast SEDA consumer rolls back its transaction, so the message stays in the queue.

A message that the route marks rollback only every time was removed before, and is now consumed again at every poll (JPA), or taken from the queue again at once, without a delay (transacted Hazelcast SEDA, as for a failed exchange). Handle such a message in the route instead, for example by moving it aside, rather than marking it rollback only every time.

A Hazelcast transaction can only be committed or rolled back by the thread that began it. When the route of a transacted (transacted=true) Hazelcast SEDA consumer continued on another thread (an asynchronous producer, or threads()), the consumer tried to commit or roll back the transaction on that thread, which failed with Transaction cannot span multiple threads! (logged as a WARN and ignored). The message was neither removed nor put back: a failed message was not taken again, and the messages, also the processed ones, were put back into the queue when the application left the Hazelcast cluster, so they were consumed again. Now the consumer thread waits for the exchange to complete and ends the transaction itself, so it takes the next message only then; use concurrentConsumers to process several messages at the same time. The exchange must complete within the Hazelcast transaction timeout (2 minutes by default, TransactionOptions): when it takes longer, the commit fails with TransactionTimedOutException, which is logged at ERROR, the transaction is rolled back and the message is consumed again, also when the route succeeded.

A hazelcast-topic consumer with reliable=true that fell behind the ringbuffer of the reliable topic (messages overwritten, or expired by its time to live, before the consumer read them) stopped receiving messages for good, while the route stayed started: Hazelcast removed its listener. The consumer now skips the lost messages, logs a WARN with their number, and goes on with the oldest message still in the ringbuffer. When Hazelcast cancels the listener for another reason, such as a destroyed topic, the consumer reports it to its exception handler (logged at WARN by default); restart the route to receive messages again. A listener cancelled because the Hazelcast instance or the CamelContext is shutting down is only logged at DEBUG.

The SQL, MyBatis and jOOQ consumers already left a message unconsumed when the route marked the exchange rollback only with markRollbackOnly(). They now leave it unconsumed when the route marks it rollback only last with markRollbackOnlyLast() too, as the JPA and Hazelcast SEDA consumers do: the SQL consumer runs its onConsumeFailed statement instead of onConsume (and no statement when onConsumeFailed is not set), the MyBatis consumer does not run its onConsume statement, and the jOOQ consumer does not delete the entity, so the next poll reads the row again. With transacted=true the SQL and MyBatis consumers break out of the batch and roll back. markRollbackOnlyLast() reaches the consumer only when no transacted() EIP has consumed the flag, so the consumer’s own transaction is the last one.

In a transacted() route that uses a JTA transaction manager, markRollbackOnlyLast() now rolls back the transaction of that transacted() block, as it already did with the camel-spring transaction error handler. Before, the transaction was committed, and the marker was then cleared, so nothing showed that the rollback was skipped. The marker is still cleared afterwards, so an outer transacted() block does not see it.

If the transacted() block in which the exchange is marked rollback only last joins the transaction of an outer block (for example a PROPAGATION_MANDATORY block inside a PROPAGATION_REQUIRED block), that shared JTA transaction is now marked rollback only, so the commit of the outer block fails (in Camel Quarkus with CamelException: Unable to commit transaction) where it used to commit, as with camel-spring (UnexpectedRollbackException). To roll back only the inner block, use PROPAGATION_REQUIRES_NEW for it.

A new muteException consumer option, enabled by default, makes a consumer with sync=true write a generic exception (java.lang.Exception with the message Exchange processing failed and no stack trace) back to the client when the exchange failed, instead of the exception of the route. With textline=true the client now receives the line java.lang.Exception: Exchange processing failed, where it used to receive the class name and the message of the exception of the route. With an encoder that accepts any object, the serialised exception no longer carries the class, message, cause or stack trace of the exception of the route. Set muteException=false to write the exception as before. transferExchange=true is not affected.

In webhook mode, Camel now registers the webhook with a secret token, which Telegram sends in the X-Telegram-Bot-Api-Secret-Token header of every webhook request, and rejects a webhook request that does not carry the token with HTTP 403. The token is the value of the new webhookSecretToken option or, when that option is not set, a value derived from the authorization token. A client that calls the webhook endpoint directly, for example in a test, must send the header too.

When Camel registers the webhook at startup (webhookAutoRegister=true, the default), nothing needs to change: each upgraded instance registers the webhook with the token, and the instances that are not upgraded yet ignore the header.

When the webhook is registered in another way, through the WebhookRoutePolicy or outside Camel, the registration made with the previous version has no secret token, and the upgraded instances reject every update until the webhook is registered again with it. Register the webhook again first, then upgrade the instances that receive the updates: instances of the previous version ignore the header. With the WebhookRoutePolicy, run the registration with the new version. Outside Camel, set webhookSecretToken, and pass the same value as the secret_token parameter of setWebhook.

The default webhook path is a hash of the endpoint URI, so adding an option to the URI, such as webhookSecretToken, changes the path. When the webhook is not registered by Camel at startup, set webhookPath to keep the path that is registered.

To restore the previous behaviour, set webhookSecretTokenEnabled=false: the webhook is then registered without a secret token, and webhook requests are not verified.

With manualAcksEnabled=true, a message whose exchange failed was left unacknowledged. For a QoS 1 message the broker never sent it again during the connection, and after receiveMaximum such messages it sent the consumer nothing more (the client completes the QoS 2 flow on its own, so QoS 2 messages did not stop the consumer). Now, for a QoS 1 message on a session that the broker keeps after the disconnect (cleanStart=false and sessionExpiryInterval greater than 0), the consumer connects again after a failed exchange (after one second, doubled for each failed exchange in a row up to maxReconnectDelay, and back to one second after any exchange that succeeds; logged at WARN), and the broker sends the message again. In all other cases (a clean session, which is the default, a QoS 2 message, or cleanStart=false without sessionExpiryInterval, where the session ends with the connection) the broker never sends the message again, so the failed message is acknowledged and the failure is left to the Camel error handler. A consumer that uses a client set with the client option leaves a failed QoS 1 message on a session that the broker keeps unacknowledged, as before; as the consumer does not connect that client, set the cleanStart and sessionExpiryInterval of the endpoint to match its connection options.

The messageExpiry option is in seconds, but its value was passed unchanged to Iggy, which reads the message expiry of a topic in microseconds, so a topic created by Camel (autoCreateTopic=true) expired its messages a million times too early (messageExpiry=3600 gave 3.6 ms instead of one hour). The value is now converted to microseconds. Topics created before keep their expiry: change it on the Iggy server. If you set messageExpiry in microseconds to work around this, set it in seconds now, or newly created topics keep their messages a million times longer than intended.

A poll of the newIssues consumer read only the newest maxResults (default 50) of the issues created since the previous poll, and the older ones were never consumed. A poll now reads every page of the search and can route more than maxResults issues; maxResults is the page size of that search (at most 50). There is no upper bound, so the first poll after a long outage or a large import can send many search requests and route many issues in one batch.

On Jira Cloud the Jira consumers now read the pages of a search with the next page token, as Jira Cloud cannot page by start index: with maxResults above 50, a search with more than 50 results failed on the second page with UnsupportedOperationException.

A netty-http consumer configured with a securityConstraint now rejects, with HTTP 400, a request whose path contains . or .. segments (including their percent-encoded %2e form). Such a path is ambiguous: the security constraint, the consumer dispatch and the route may each interpret it differently, so with matchOnUriPrefix=true and a specific inclusion such as /admin/*, a request like /foo/../admin/x (or its encoded /foo/%2e%2e/admin/x form) could be matched against the inclusions and exclusions in a different form than the one the route handles. Rejecting it up front keeps the constraint decision and the routed path consistent. A well-behaved HTTP client normalizes dot-segments before sending, so normal traffic is unaffected.

For the same reason, such a consumer also rejects with HTTP 400 a request whose path contains an empty segment (//), a ; path parameter (also as %3b) or a \ (also as %5c). A backend the route forwards the request to may collapse the empty segment, strip the path parameter or treat the backslash as a /, and so act on a different path than the one the constraint was checked against. A route that needs matrix parameters (;) must not configure a securityConstraint on the same consumer.

This applies only when a securityConstraint is configured; a consumer without one is unchanged, and continues to receive the request path as sent.

A hashicorp: property without an engine, such as {{hashicorp:mysecret}} or {{hashicorp:mysecret#field}}, now reads the secret from the secret engine. Before, it read from the engine of the hashicorp: property resolved before it (or from a null engine), and {{hashicorp:mysecret#field}} always resolved to no value. Properties with an engine, such as {{hashicorp:secret:mysecret#field}}, are not affected.

A hashicorp: property without an engine and with a version, such as {{hashicorp:mysecret@2}}, now reads version 2 of the secret mysecret in the secret engine. Before, the @2 was kept as part of the secret name.

A hashicorp: property with a field of a secret that does not exist, such as {{hashicorp:secret:missing#field}}, now resolves to no value, as it already did without a field, so its default value or an optional placeholder ({{?hashicorp:secret:missing#field}}) applies. Before, without a default value, it failed with a NullPointerException.

The aws2-ddbstream consumer now reads a closed shard to its end before it reads its child shards, and uses streamIteratorType only for its start position. Before, records left in a closed shard could be skipped, and after a shard rotation the consumer started again from streamIteratorType: with FROM_START it routed records of the stream again, and with FROM_LATEST it skipped records already written to the new shards.

BeanIOSplitter read a file body with the default charset of the JVM, and a stream or byte array body with the charset of the exchange or the default charset of the JVM; its encoding option was not used. A file consumed with charset=ISO-8859-1, or a splitter with setEncoding(StandardCharsets.ISO_8859_1), had every non-ASCII character replaced. The splitter now decodes a file, stream or byte array body with the charset of the exchange (the CamelCharsetName header or exchange property, as set by the charset option of the file consumer), else with its encoding (default: the default charset of the JVM). A String or Reader body is read as before, and other text (such as a StringBuilder, which failed before) is read as text.

A BigDecimal, Double or Float field whose @DataField (or @KeyValuePairField) has no precision and no pattern was marshalled with at most three decimals, rounded: 1.23456 was written as 1.235 and 0.000123 as 0 (since Camel 4.22, CAMEL-24168; up to Camel 4.21 the default precision = 0 wrote these fields without any decimals). It is now written with all its decimals, so a record that is unmarshalled and marshalled again is the same text. A Double that is the result of a calculation is written with all its digits too (0.1 + 0.2 as 0.30000000000000004, before 0.3). Set precision to get a fixed number of decimals, as before.

The Smooks component and SmooksProcessor now parse a message body that is already a Smooks Source (org.smooks.io.source.StringSource, ReaderSource, StreamSource, ByteSource or URLSource) with the same XML reader settings as the other message bodies, so external entities in it are only resolved when allowExternalEntities is true. Before, such a body was handed to Smooks as it was. The bytes of a StreamSource, ByteSource or URLSource are decoded with the exchange charset, or UTF-8, as before. These bodies are now parsed into a DOM before Smooks processes them, which uses more memory for very large inputs. DOMSource and JavaSource bodies are unchanged.

A Smooks configuration whose <reader> declares no class only sets handlers, features or parameters of the default XML reader. The Smooks component, SmooksProcessor and the Smooks data format now apply allowExternalEntities to such a configuration as they do to a configuration without a <reader>, so the handlers and features of that reader no longer take part in parsing the XML unless allowExternalEntities is true. Configurations that declare a reader class, such as EDI, CSV, JSON, DFDL or a custom reader, are unchanged.

A document with a document type declaration (<!DOCTYPE …​>) is now processed with these settings for every body type, String, byte[] and InputStream bodies included, which failed before: the entities of its internal subset are expanded, and the declaration itself is not passed on to Smooks.

Set allowExternalEntities=true on the endpoint or on the data format for documents that rely on external entities or an external DTD.

When the HTTP server (camel.server.enabled=true) and the HTTP management server (camel.management.enabled=true) have the same port (both default to 8080), the HTTP server serves the management endpoints. It cannot apply these options of the management server, which were ignored without notice:

Camel now fails to start when the management server shares the port and one of them is configured, with a message that lists them. Set camel.management.port to another port, so that the management server runs a server of its own and applies them. To keep a single port, remove them and configure the HTTP server instead: for example, authentication configured on the HTTP server for /* also applies to the management endpoints.

The producer used the bucket named in the CamelIBMCOSBucketName header instead of the bucket of its endpoint. The consumer sets that header to the bucket an object was consumed from, so a route from one bucket to another (from("ibm-cos:source…​").to("ibm-cos:target…​")) stored each object back in the source bucket, and with the default deleteAfterRead=true the consumer then deleted it there. The producer now ignores CamelIBMCOSBucketName and uses the bucket of the endpoint, or the bucket named in the new CamelIBMCOSOverrideBucketName header (IBMCOSConstants.OVERRIDE_BUCKET_NAME), as camel-aws2-s3, camel-minio and camel-google-storage do since 4.10. A route that sets CamelIBMCOSBucketName to choose the bucket of a producer operation (for example createBucket or deleteBucket) must set CamelIBMCOSOverrideBucketName instead.

The ical data format used one ical4j CalendarBuilder for all exchanges. Two exchanges that were unmarshalled at the same time could get the events of each other, or the calendar of the other exchange. Each unmarshal now uses its own builder.

A builder also has its own time zone registry, so a VTIMEZONE of one calendar is no longer used for the calendars unmarshalled after it. A date with a TZID that is not a standard time zone and that its calendar does not define is now read as a local date-time without a zone (getDate() returns a LocalDateTime); before, it was read with the definition of an earlier message, if there was one. A calendar that defines a TZID an earlier message has defined differently is now read with its own definition.

With the default ignoreFirstRecord=true, marshalling a List<Map<String, Object>> skipped the first map, so the first data row was missing from the output, for delimited and fixed-length files alike (the header line of a delimited file is written from the column names, not from the first map). Every map of the list is now written, and ignoreFirstRecord only applies to unmarshal. A route that set ignoreFirstRecord=false to work around this is not affected; a route that added a dummy first map now gets it in the output too.

The commit consumer read only the 100 newest commits of the branch at each poll, so when more than 100 commits were pushed between two polls, the older ones were never routed. A poll now reads the commits up to the last routed one (at most 1000, the number of commits the consumer remembers), and can route more than 100 commits. When the last routed commit is no longer on the branch, only the 100 newest commits are considered, as before. GitHub lists the commits by committer date, newest first, so this covers a linear history: the commits that a merge brings in keep their older dates and can be listed after the last routed commit, and they are not routed, as before.

Each routed commit costs one GitHub API request for its author, plus one for each author or committer not looked up before, so a poll that catches up on many commits can send about 1000 requests instead of about 100. When the rate limit is reached, the GitHub client waits inside the poll until the limit resets (its default rate limit handler), and stopping the route waits for that poll.

When the endpoint it selects uses a security policy other than None, the milo-client and milo-browse components now validate the certificate of the OPC UA server. Before, any server certificate was accepted, and no option allowed to validate it.

Configure the trusted certificates with the new trustListDirectory option: put the certificate of the server, or of the CA that issued it, in the trusted/certs directory of the trust list. A server certificate that does not chain up to a trusted certificate is written to rejected/certs, from where it can be moved to trusted/certs once it has been checked. The trust list also refuses a server certificate outside its validity period, revoked by a revocation list of the trust list, or whose application URI differs from the one of the server. A server certificate issued by a CA is refused with Bad_CertificateRevocationUnknown when the trust list holds no revocation list of that CA: add the CRL of the CA (an empty one is enough) to trusted/crl or issuer/crl. A custom validator can be configured with the new certificateValidator option instead.

With neither option, the client does not connect to such an endpoint. It logs a WARN message Failed to connect: The certificate of the OPC UA server cannot be validated, followed by the endpoint and its security policy, and tries again after reconnectTimeout (10 seconds by default). A producer fails with IllegalStateException: No connected, caused by the same message. A server certificate refused by the trust list or by a certificateValidator is logged at WARN as Failed to connect, because a certificate or security check failed. To restore the previous behaviour, set the new trustAllCertificates option to true. This is insecure: the client then does not authenticate the server.

The certificate that the user name and password are encrypted with is checked by the same validator. Endpoints that use the security policy None are not affected.

When knownHostsResource is set, the entries of the known_hosts file are now matched as OpenSSH matches them, against the host name or address the client connects to, written host for port 22 and [host]:port for another port:

As before, a server whose host has entries without a marker is rejected when it presents a key that none of them lists, whatever the value of failOnUnknownHost, which only applies to a host without such an entry: @revoked and @cert-authority entries do not list a host. Check that the known_hosts file has an entry for the host name or address, and the port, that each endpoint is configured with.

ZipAggregationStrategy replaced an entry of the zip file when a later message had the same entry name, for example two files orders.csv from different folders of a recursive file consumer (the folders are not kept by default), so the content of the earlier file was lost. The later entry is now added with a number before its extension: orders (1).csv, orders (2).csv, and so on. Entry names can therefore differ from the file names (or the CamelFileName header). Use preserveFolderStructure=true to keep the folders in the entry names instead.

A milo-client or milo-browse connection now handles the outcome of its write, method call, read and browse requests on a thread pool of its own named MiloClient, and runs its reconnects on a single thread named MiloClientReconnect. Before, it used the shared scheduled executor of Milo (milo-shared-scheduled-executor) for both. A route that continues after an awaited request now runs on a thread of the MiloClient pool. The pool has up to as many threads as there are processors, which end after they have been idle for the keep-alive time of the default thread pool profile (60 seconds). With virtual threads enabled and more than one processor, it starts a virtual thread for each task instead. The MiloClientReconnect thread starts with the first reconnect of the connection, and its reconnects run one after the other. The threads of a connection end when it is closed.

A MiloClientConnection created outside an endpoint needs a CamelContext, set with setCamelContext, before it is used.

The LRA saga service now joins, completes or compensates an LRA only when its URL is under the configured LRA coordinator (coordinatorUrl followed by coordinatorContextPath). A message whose Long-Running-Action header holds the URL of another coordinator now fails, instead of the saga service calling that URL.

If your participants reach the same coordinator under different URLs, for example with different host names, list the other coordinator URLs, including the context path, in the new allowedCoordinatorUrls option (camel.lra.allowedCoordinatorUrls).

This also applies to the LRAs the service starts itself, which a nested saga route looks up again: when the coordinator returns LRA URLs under another base URL than coordinatorUrl, for example behind a proxy, add that base URL to allowedCoordinatorUrls as well.

The LRA saga service now logs a warning at startup when no callbackSecret is configured: the callbacks that the LRA coordinator sends to the participant endpoints are then not verified, so these endpoints must only be reachable by the coordinator. The Saga EIP documentation describes how to sign them.

A saga option named like a parameter of the participant callback URLs, in any case (Camel-Saga-Compensate, Camel-Saga-Complete, Camel-Saga-Signature or Camel-Saga-Lra), now fails the creation of its route, with or without a callback secret. The value of such an option could not be read back from the callback before.

The events fired by the AI components now share a common contract, org.apache.camel.ai.AiEvent (a CamelEvent of the new CamelEvent.Type.Ai), instead of each being a component-specific CamelEvent.Type.Custom event. Events that relate to a single exchange implement the exchange-backed subtype AiEvent.ExchangeAiEvent (the root AiEvent itself is not an ExchangeEvent). This lets an EventNotifier recognise AI activity — and route it to metrics or tracing — by type and by the AiEvent sub-interfaces, without depending on an AI component.

The events shipped in 4.23.0 are affected:

Their getType() now returns CamelEvent.Type.Ai rather than CamelEvent.Type.Custom, and they are now CamelEvent.ExchangeEvent`s (via `AiEvent.ExchangeAiEvent). An EventNotifier that recognised these events by event.getType() == CamelEvent.Type.Custom must match on CamelEvent.Type.Ai instead, or — preferably — on event instanceof org.apache.camel.ai.AiEvent (or one of its sub-interfaces), which no longer requires a dependency on the AI component. The concrete event classes and all their accessors are unchanged, so code that references them directly is not affected.

Because the shipped AI events are now ExchangeEvent`s (via `AiEvent.ExchangeAiEvent), a notifier that filters on instanceof ExchangeEvent now also receives them. AI events are their own category: a new ignoreAiEvents flag (EventNotifier.setIgnoreAiEvents(boolean), default false) opts a notifier out, and ignoreExchangeEvents does not drop AI events (so an AI-observability notifier can keep ignoreExchangeEvents=true for performance). Camel’s own exchange-oriented notifiers (the debugger, the dev-console event ring, the micrometer and OpenTelemetry metrics exchange notifiers) set ignoreAiEvents=true so AI events do not reach them; a custom exchange-focused notifier that should not see AI events should do the same.

OAuthBearerTokenProcessor no longer creates or updates the OAuth session, and no longer sets the camel.oauth.session cookie nor the CamelOAuthSessionId header: a bearer token authenticates the request that carries it, and nothing else. The authenticated UserProfile is available in the CamelOAuthUserProfile exchange property (OAuth.CAMEL_OAUTH_USER_PROFILE). A route that read the profile from the OAuth session after OAuthBearerTokenProcessor must read it from that exchange property instead.

When the message comes from platform-http (on Vert.x or on Spring Boot), from a servlet based HTTP consumer (camel-servlet, camel-jetty) or from camel-netty-http, the bearer token and the session cookie are now read from the Authorization and Cookie headers of the HTTP request only. A query or form parameter of the same name, which these consumers also map into the message headers, is no longer used for them, and neither is an Authorization or Cookie message header that the route sets itself. For example .setHeader("Authorization", simple("Bearer ${header.X-Forwarded-Access-Token}")) before OAuthBearerTokenProcessor now results in a 401 response. A route that takes the token from elsewhere can validate it with OAuthHelper.validateOAuthToken from camel-support instead.

For any other message, such as one from camel-undertow, the processors keep reading the message headers, but leave out a value that also appears in the query string of the request.

The consumer now reads the charset parameter of the request Content-Type whatever the case of its name, as camel-undertow and camel-netty-http do: a body sent with Content-Type: text/plain; Charset=ISO-8859-1 is decoded as ISO-8859-1 and CamelCharsetName is set. Before, only charset= in lower case was read and such a body was decoded as UTF-8. An empty charset parameter (charset= or charset="") now counts as no charset, as in camel-undertow, camel-netty-http and camel-http-common (CAMEL-25355); before, converting the body to a String failed with 500.

The validate and route-coverage goals read Java routes with the Java DSL parser of camel-java-io instead of camel-route-parser (Roaster). XML routes are read as before. The parser reads every configure() method of a source file, including those of a route builder created inside a test, so validate can find and validate endpoints it did not see before. An endpoint uri that is only a method call, such as from(inboxQueue()), is not validated (it was validated as a property placeholder without a component before); with logUnparseable=true it is logged.

The route-parser plugin (camel route-parser) and its camel-jbang-plugin-route-parser artifact are removed. Use camel cmd route-structure MyRoute.java instead: it prints the structure of the routes of a Java source, read without compiling it, and of YAML and XML sources too. If you installed the plugin, remove it with camel plugin delete route-parser.

The camel_component_properties MCP tool is removed. It listed the endpoint options of a component as camel.component.<scheme>.<option> keys, which camel run and camel_configuration_validate reject: only the component options can be set that way. Use camel_catalog_doc instead: each component option in its answer carries its application.properties key as configKey.

camel_catalog_doc without optionsFilter now lists the required options and the first 20 other options of a component in full, and the rest by name in moreOptions (limit lists more in full), and an answer is cut at 18 000 characters with a marker. An option of both the endpoint and the component is listed once, with scope set to endpoint,component and its configKey, instead of twice, and matchedOptions counts option names. A name that only matches a word of an EIP title (such as retry) no longer returns that EIP: the answer is a not-found with suggestions.

The wasm endpoint now runs WASI Preview 1 command modules (the body is standard input, standard output becomes the body, the exit code and standard error are in CamelWasmExitCode and CamelWasmStderr) and no longer supports the custom alloc/dealloc and JSON message ABI. The URI path is now the module (wasm:classpath:upper.wasm); the function name and the module option are removed, and a header reaches the module only when listed in environmentHeaders. To migrate, turn the function into a program that reads standard input and writes standard output, built for wasm32-wasip1 (Rust) or with GOOS=wasip1 GOARCH=wasm (Go).

The endpoint runs every exchange on a new instance of the module, so a module can no longer keep state from one message to the next. The 4.23 note that a failed call discards the Wasm instance no longer applies.

The wasm language is removed: the wasm expression of the Java, XML and YAML DSLs, WasmExpression of the model, and WasmLanguage, WasmFunction, WasmSupport, Wasm.FN_ALLOC and Wasm.FN_DEALLOC of camel-wasm. Call the module with the wasm endpoint as a route step instead, for example .to("wasm:classpath:transform.wasm"), built as a WASI command module as described above, and use its output (the new message body) in the next steps.

The following API of camel-wasm is removed or changed with the old ABI:

camel-wasm has a new dependency, run.endive:compiler, which brings in ASM (org.ow2.asm). It is used by the new compile option of the endpoint (default false). The module is now loaded once per endpoint and no longer by every producer, so stopping and starting a route does not read the module again: remove the route and add it again, or restart the application, to load a module that has changed.

When the subscription of a consumer ends with an error (for example a request to the node that fails inside BLOCK_OBSERVABLE or TRANSACTION_OBSERVABLE, or a node that cannot be reached when the route starts), the consumer now subscribes again every 15 seconds until it succeeds. The error is routed as before, and logged at WARN; the failed attempts that follow are logged at DEBUG. Previously the consumer received nothing more while the route stayed started. A new subscription starts at the latest block, so the blocks between the error and the new subscription are not routed. REPLAY_BLOCKS_OBSERVABLE, REPLAY_TRANSACTIONS_OBSERVABLE and an ETH_LOG_OBSERVABLE with fromBlock set to a block number are not subscribed again, as that would route the same blocks or logs again.

XMPP URIs that differ only in the participant or the user are now separate endpoints. Before, the component could return an endpoint that was created for another participant or user, and messages went to the wrong participant.

All the consumers and producers of one account (the same host, port, service name, user, password, resource and login settings) now share one XMPP connection, also across endpoints. So an account has one session on the server instead of one per endpoint, and the server no longer closes one of them with a conflict error. The connection is closed when the last route that uses the account stops. With the connectionConfig option, endpoints share a connection only when they refer to the same ConnectionConfiguration instance (for example the same bean in the registry).

XmppEndpoint.createConnection() now creates a new connection on every call, instead of returning the connection of the endpoint, and an endpoint no longer disconnects a connection when it stops.

With subscriptionType Shared, Failover or Key_Shared, a consumer that could not subscribe when the route started (for example a broker that could not be reached within the operation timeout of the Pulsar client) was only logged at ERROR, and the route started with fewer consumers than numberOfConsumers, or with none, and never subscribed them again. Now the consumers that did subscribe are closed and the route fails to start with the error of the Pulsar client, as it already did with Exclusive. When the route starts with the CamelContext, the CamelContext then fails to start, unless the supervising route controller (camel.routecontroller.enabled=true) is used, which starts such a route again. With messageListener=true (the default) the consumers that did subscribe may already have received messages before they are closed, and messages they received but did not acknowledge can be delivered again once the route has started.

A message header whose value is a java.util.Collection or an object array (as the HTTP consumers map a request header that occurs more than once) was sent as one HTTP header with the toString() of the value, for example [a, b]. The producer now sends one HTTP header per value. A collection or an object array that is empty, or that holds only null values, now sends no header (an empty List was sent as the header value []).

Every other value is converted to one String and sent as one header as before: a String (also when it contains commas), a byte[] and the other primitive arrays, a Map, and a Vert.x JsonObject or JsonArray (sent as JSON). A route that needs the old single header can set the header to a String, for example with String.valueOf(list).

When configuring TLS through SSLContextParameters with a standalone TrustManager instance (via TrustManagersParameters.setTrustManager(…​)), Vert.x components now wrap and apply the configured TrustManager. Previously, only TrustAllTrustManager.INSTANCE and KeyStore-backed configurations were applied, and other standalone TrustManager instances were not set on the underlying Vert.x options.

When both a TrustManager and a keystore are configured on TrustManagersParameters, the TrustManager is now used, as with the other components that use SSLContextParameters; before, the keystore-based trust options were used.

A message header whose value is a java.util.Collection or an object array (as the consumer maps a request header that occurs more than once) is now sent as one HTTP header per value. The Knative HTTP producer sent it as one HTTP header with the toString() of the value, for example [a, b], and the reply of the consumer sent only its last value. A collection or an object array that is empty, or that holds only null values, sends no header (the producer sent an empty List as the header value []).

Every other value is one header. A String is sent as before, also when it contains commas, and the reply still sends no header for a blank String. A byte[] is now converted to a String with the type converter (the producer sent its toString(), such as [B@1dc9f5ad, and the reply only its last byte as a number). The producer sends a Map and a Vert.x JsonObject or JsonArray as before, as their toString() (JSON for the Vert.x types). The reply now does the same: it sent only the last entry of a Map or JsonObject in the form key=value, and only the last element of a JsonArray.

A route that needs the old single header of the producer can set the header to a String, for example with String.valueOf(list).

A message header whose value is a java.util.Collection or an object array (as the HTTP consumers map a request header that occurs more than once) was sent as one HTTP header with the values in the form [a, b]. The producer now sends one HTTP header per value, as camel-vertx-http and camel-knative-http do. Null values are skipped, and a collection with one value is sent as one header with that value, as before.

Every other value is sent as one header. A String is sent as before, also when it contains commas. A byte[] or a char[] is now converted to a String with the type converter, for example abc (it was sent as [97, 98, 99]), and a Map is sent as its toString(), such as {k1=v1, k2=v2} (it was [k1=v1, k2=v2]). The other primitive arrays, an Iterator, a java.util.stream.Stream and an Iterable that is not a collection are sent in the form [a, b] as before. A route that needs the old single header can set the header to a String, for example with String.valueOf(list).

This also applies to camel-graphql, which sends its requests with camel-http.

The value of a Switch case and the uriDelimiter of the Dynamic Router EIP were used as written, so a property placeholder or a route template parameter in them never matched (Switch) or did not split the slip (Dynamic Router). They are now resolved at startup like the other EIP options; a placeholder of a property that does not exist now fails the route at startup.

A Kamelet endpoint creates a route from the Kamelet’s template. When the endpoint is created while the CamelContext runs and is shut down later, its route is now stopped and removed as well; before, it stayed behind and kept running. This applies to an endpoint that is used once and discarded (toD, recipientList or routingSlip with cacheSize=-1), which kept one more route for every message. It also applies to a route added at runtime (such as a dev-mode reload or CamelContext.addRoutes) that consumes from a Kamelet (from("kamelet:my-source")): removing that route now also removes the route of the Kamelet. A route id given in the uri (kamelet:my-source/myRoute or routeId=) is shared by the endpoints that use it, so such a route is not removed. Routes created when the CamelContext starts are not changed.

The undertow producer writes the path, query and header values of the outgoing request to the socket one character at a time, without validating them. A carriage return or line feed therefore broke the request into further lines, and a character above 0xFF was written as a single, different byte (for example U+010A became a line feed). The producer now refuses to send a request path, query or header value that contains a control character or a character above 0xFF, and fails the exchange with an IllegalArgumentException instead. A space and a tab, which do not change the framing, are still allowed. Routes that put a percent-encoded control character (such as %0D%0A) into the CamelHttpPath or CamelHttpQuery header, which the producer decodes before building the request, are the ones most likely to be affected.

On a WebSocket path whose producer applies a security provider or allowed roles, a connection could be accepted while only the producer served the path, before its consumer was started for the first time. Such a connection ran the producer checks but not the custom handlers the consumer configures, as those handlers run only for consumers. Once the consumer was started, the connection was still treated as having passed the consumer checks, so its messages reached the route and it kept receiving what the producer sent.

Once a consumer that configures handlers is started on a path, a connection opened on that path before the consumer first ran is no longer served: its messages no longer reach the route and it no longer receives what the producer sends, and the connection is closed. Clients that open a connection in this window must reconnect after the consumer has started.

The saveBulk and executeTransaction operations of dapr:state built their request but never sent it to Dapr, so nothing was stored and the exchange completed without an error. The requests are now sent, and the producer waits for the answer like the other state operations: the states are stored, and a request that Dapr rejects (or a sidecar that cannot be reached) fails the exchange.

The pubnub producer no longer reads the CamelPubNubChannel header. This header is set by the pubnub consumer to the channel a message was received on, and the producer used it instead of the channel configured on its endpoint, so a route from one pubnub endpoint to another sent each message back to the channel it came from. The producer now uses the channel of its endpoint, for every operation. To choose a different channel for a message, set the new CamelPubNubOverrideChannel header (PubNubConstants.OVERRIDE_CHANNEL). Routes that set CamelPubNubChannel to pick the channel of a pubnub producer must set CamelPubNubOverrideChannel instead.

The docker:events consumer subscribes again when its event stream fails or ends (for example when the Docker daemon restarts): after 1 second, then with a delay that doubles up to 30 seconds while the daemon cannot be reached. Before, it stayed started without receiving any event. The events of the time without a stream are not received. Stopping a docker:events or docker:stats consumer now closes its stream: before, the stream stayed open, and a route that was stopped and started again received every event once more for each restart.

The keycloak consumer (eventType=events and eventType=admin-events) reads, after its first poll, all the events since the previous poll, page by page, with maxResults as the page size. Before, it read only the latest maxResults events and moved past the older ones, so when more than maxResults events happened between two polls the older ones were never consumed. A poll can now route more than maxResults events. The first poll still reads the latest maxResults events.

The producer wrote with the batching write API of the InfluxDB client: the point was put into a buffer of the client and sent later by a background thread, so the exchange completed before anything was written, and a write that InfluxDB rejected (a line it cannot parse, an unknown bucket, a token that is not authorized) or could not receive was only logged by the client while the route continued as if the data had been stored. The producer now writes with the synchronous write API: the exchange continues when InfluxDB has answered, and a failed write fails the exchange with a CamelInfluxDb2Exception (cause: the InfluxException of the client), which the error handler can redeliver.

Each exchange is now one write request, where the client used to collect the points of up to one second into one request, and the client no longer retries a write in the background. Routes with a high message rate can send a Points, Measurements or Records body (for example from an aggregator) to write many points with one request.

The user and password are now offered only to the nodes the client talks to: the hosts of hostAddressesList and, when enableSniffer is set, the nodes the sniffer finds, matching the scheme, host and port. Previously they were registered for any host. A request to another host, including the host of a node with another scheme or port, is now sent without them. A client set with the restClient option is not changed.

The addComment, addIssueLink, addWorkLog, attach, deleteIssue, transitionIssue and watchers producers (and addIssue for its watchers) sent their request without waiting for the answer, so the exchange continued before Jira had done the work, and a request that Jira rejected (for example no permission, or a transition that is not allowed) was not noticed. They now wait for the answer, as addIssue and updateIssue already did, and a rejected request fails the exchange with the RestClientException of the Jira client. Routes that relied on such failures being ignored must handle the exception, for example with onException(RestClientException.class).handled(true).

A producer that sends several requests can fail after some of them were done: transitionIssue can fail on its comment after the transition was made, watchers and addIssue can fail after some of the watchers were changed (addIssue sets the created issue as the message body before it adds the watchers), and a retry or redelivery repeats the earlier requests.

With preserveMessageQos=true, a message without a JMSExpiration (header missing or 0) was sent with no time to live, so it never expired, even when the endpoint has a timeToLive and, for request/reply, although Camel sets the requestTimeout as time to live otherwise. Such a message now gets the time to live of the endpoint, as the option documents. Set disableTimeToLive=true to send it without time to live.

The pulsar producer no longer passes the default initialSequenceId=-1 to the Pulsar client, so the client continues after the last sequence id the broker has for the producerName. Before, every start began again at sequence id 0, and with deduplication enabled on the broker the messages sent after a restart were dropped as duplicates (the send succeeded) until the sequence ids passed the ones of the previous run. A configured initialSequenceId of 0 or more is still used as before.

Since Camel 4.0 (the upgrade to Twitter4J 4.1, whose Query is immutable) the twitter-search endpoint sent only the keywords. The consumer ignored filterOld (default true), lang, count and the geolocation options, so it routed the same tweets again at every poll. The producer ignored sinceId, lang, count and the CamelTwitterSinceId, CamelTwitterMaxId, CamelTwitterSearchLanguage and CamelTwitterCount headers. The options are applied again: a poll returns only the tweets newer than the last one consumed, and a page has count tweets (default 5; Twitter’s own default of 15 applied before). Raise count and numberOfPages if a search can match more tweets than that between two polls. A consumer with type=direct returned nothing when keywords were given, and now runs the search at startup.

The insert, delete, update and upsert operations of the producer ignored the answer of Kudu. The Kudu client does not throw for a row that Kudu rejected; it returns a row error, for example for an insert of a key that is already present, or for an update or a delete of a row that is not found. Such an exchange completed as if the row had been written. A write that timed out or could not reach a tablet server was reported the same way, and completed the exchange too; for such a write it is not known whether the row was written. The producer now fails the exchange in both cases with a KuduRowErrorException (getRowError() returns the row error of the Kudu client, whose status tells the kind of error). Routes that relied on rejected rows being skipped silently can use the upsert operation, or handle the exception, for example with onException(KuduRowErrorException.class).handled(true).

The producer also closes the Kudu session of each operation. The sessions stayed registered with the Kudu client until the client was closed, one more for every exchange.

When sslContextParameters is set (on the endpoint, or with useGlobalSslContextParameters on the component), the MLLP producer now checks that the certificate of the server matches the host it connects to, with the same rules as an HTTPS client. Before, it accepted any certificate trusted by the trust store, whatever host the certificate was issued for.

A producer that connects with a host name or an IP address that the certificate does not list now fails the TLS handshake; an IP address must be listed as a subject alternative name of the certificate, and a producer URI without a host name (such as mllp://8888) cannot pass the check. Use a certificate that matches the host of the endpoint, or set the new hostnameVerification option to false to keep the previous behaviour.

With streamingUploadMode=true and namingStrategy=random (or timestamp), the first file uploaded by a producer was named after keyName alone (for example camel.txt), and only the later files got a UUID (or a timestamp) after keyName. A producer that was started again (a restart of the route or of the application), or another producer with the same keyName, wrote its first file to the same key and replaced the first file written before. Every file now gets the UUID (or the timestamp), the first one too: camel-<uuid>.txt. The progressive naming strategy is unchanged.

With sortEntries=true the atom consumer sorted the entries of a feed by their published date and routed them from the newest to the oldest one. With the default idempotent strategy (which skips an entry that is not newer than the one routed before it) only some entries of a feed were routed, and the others were skipped.

This is fixed. The entries are now sorted by their updated date (by the published date for an entry without an updated date), which is the date the idempotent strategy compares, and they are routed from the oldest to the newest one, as camel-rss does and as Camel 3.x did. Entries are no longer skipped because of the routing order, also when an older entry was updated after newer ones were published.

Routes using sortEntries=true with idempotent=false get the entries in this order too: the entry that was updated first is routed first, where the entry that was published last was routed first before.

The user and password are now offered only to the nodes the client talks to: the hosts of hostAddresses and, when enableSniffer is set, the nodes the sniffer finds, matching the scheme, host and port. Every node of a multi-host cluster still receives them. Previously they were registered for any host. A request to another host, including the host of a node with another scheme or port, is now sent without them. A client set with the client or openSearchClient option is not changed.

The consumer polls from the newest event time it has seen, so an event that CloudTrail made visible after a newer one was never routed. Now, every lookBackInterval (default 1 minute), the consumer also looks up the events from lookBackWindow (default 10 minutes) before now up to that newest event time, and routes those it has not routed yet. The normal polls send the same LookupEvents requests as before. The late-event lookup adds ceil(N / maxResults) requests per lookBackInterval, at most one per poll, where N is the number of events in that range: with the defaults one request per minute up to 50 events in 10 minutes, 20 per minute for 1000 events, and none once no event was seen for 10 minutes. AWS allows two LookupEvents requests per second per account and Region. Set lookBackWindow=0 to disable the late-event lookup.

When the consumer lists the bucket, a failure to get one of the listed objects (or to download its content) no longer fails the poll, as long as another object of that listing could be got: the object is skipped, the other listed objects are consumed in that poll, and the skipped object is tried again by a later poll. An object that no longer exists (for example deleted by another consumer after the listing) is skipped with a log line at DEBUG. Any other failure is given to the exception handler of the consumer, with the key in the message: by default that is a WARN with the stack trace, and with bridgeErrorHandler=true the route’s error handler gets it. This happens at every poll that lists an object that can never be read (for example archived, or access denied), until it can be read or is removed from the bucket. Such a poll is a successful poll, so it does not count for backoffErrorThreshold.

The poll still fails, as before, when none of the listed objects could be got and at least one get failed with an error other than that the object no longer exists (for example expired credentials, no permission to get objects, throttling): the failure of the first object is then the failure of the poll, and backoffErrorThreshold applies. In both cases the objects are no longer kept in the inProgressRepository; before, the object (or a new object with the same key) was skipped by all later polls until the endpoint was restarted. With the fileName option, a failed get still fails the poll.

When the length of the body is known without reading it (a byte[], String, file, Path or cached stream), the producer now uploads it with that length, and the CamelAwsS3ContentLength header is only used for a stream whose length is not known. Previously the header took precedence: after a route changed the body of an object read by the aws2-s3 consumer (which sets the header), a longer body was stored cut to the old length and a shorter one failed.

When sslContextParameters is set (on the endpoint, or with useGlobalSslContextParameters on the component), the producer, and the consumer with clientMode=true, now check that the certificate of the server matches the host of the endpoint, with the same rules as an HTTPS client. Before, any certificate trusted by the trust store was accepted, whatever host the certificate was issued for.

A connection to a host name or an IP address that the certificate does not list now fails the SSL handshake; an IP address must be listed as a subject alternative name of the certificate. Use a certificate that matches the host of the endpoint, or set the new hostnameVerification option to false to keep the previous behaviour.

MINA does not pass a failed handshake on as an error: the producer fails with a timeout (after writeTimeout, or timeout while waiting for a reply), and the handshake error is logged at ERROR level by org.apache.mina.filter.ssl.SslHandler. A producer that starts timing out after the upgrade should be checked for a certificate that does not list the host.

The ftps endpoint now checks, on the control connection, that the certificate of the server matches the host of the endpoint, with the same rules as an HTTPS client, with sslContextParameters as well as with the ftpClient.trustStore.* options. Before, any certificate accepted by the trust manager was accepted, whatever host the certificate was issued for. Data connections are not checked by host name.

A connection to a host name or an IP address that the certificate does not list now fails the TLS handshake, before login; an IP address must be listed as a subject alternative name of the certificate. Use a certificate that matches the host of the endpoint, or set the new hostnameVerification option to false to keep the previous behaviour. A custom ftpClient set on the endpoint is not changed.

With camel.vault.aws.refreshEnabled=true and without SQS notification, each check now reads every page of the PutSecretValue and UpdateSecret events since the previous check, including the events in the same second as the newest event seen before, so an update is no longer missed when more events than one page happened in between. The first check looks for the updates made after the task started: an update made before the start no longer reloads the context. A check sends two LookupEvents requests, one per event name, and one more per further 50 updates (before: always one request, for all Secrets Manager events); reads of secrets no longer add requests. LookupEvents allows two requests per second per account and Region.

With streamingUploadMode=true and timestampGroupingEnabled=true, the upload of a time window is completed when it reaches batchMessageNumber messages (10 by default) or batchSize bytes, or when streamingUploadTimeout runs. A later message of the same window started a new upload with the same key, and S3 replaced the object of the first upload with it, so the messages of the earlier uploads were lost (unless the bucket is versioned). A later upload of a window now gets the number of the uploads of that window before it after the time range: for example grouped-messages_20240101_0800_0800-0805.txt, then grouped-messages_20240101_0800_0800-0805-1.txt, grouped-messages_20240101_0800_0800-0805-2.txt, and so on. The first upload of a window keeps the name it had. The first time a producer uploads a window, it lists the objects of the window in the bucket (one ListObjectsV2 request per window), so after a restart it continues after the highest number stored; this needs the s3:ListBucket permission, and without it the producer logs a WARN and numbers the uploads of the window from the first one. These keys do not sort in upload order (-1 sorts before the first upload’s name, -10 before -2). Producers running at the same time with the same keyName still need distinct key names.

When a cached shard iterator has expired (an iterator is valid for 5 minutes, so after a route was suspended for longer, or with a delay or back-off above 5 minutes), the consumer now continues after the last record it routed from that shard. Previously it requested a new iterator of the configured iteratorType: with TRIM_HORIZON (the default) it routed all the records of the shard again, with LATEST it skipped the records stored meanwhile.

A shard created by a split or a merge while the consumer is running is now read from its first record, whatever the iteratorType. Previously, with LATEST, the records stored in the new shard before the consumer listed it were skipped. The shards that exist when the consumer starts are read from the configured iteratorType, as before.

The accessToken (with its jwtAuthorizationType) is now added to a request only when the request goes to the scheme, host and port of httpUri, and the username and password are registered for that authority only. Previously neither was bound to the authority of httpUri. A request to another authority, including the same host with another scheme or port, is now sent without them. A route that needs to authenticate to another authority must address it in httpUri. When proxyHost is set, the username and password are no longer offered to the proxy when it asks for authentication.

The producer also no longer takes the request URL from the CamelHttpUri, CamelHttpPath, CamelHttpQuery and other camel-http control headers of the message. It did so since Camel 4.19, when the component moved onto camel-http; the request now always goes to httpUri, as it did before. For the same reason the CamelHttpMethod and CamelHttpProtocolVersion headers no longer apply, and the request is always a POST.

The user and password are now offered only to the nodes the client talks to: the hosts of hostAddresses and, when enableSniffer is set, the nodes the sniffer finds, matching the scheme, host and port. Previously they were registered for any host. A request to another host, including the host of a node with another scheme or port, is now sent without them. A client set with the client option is not changed.

A RestClient set with the client option of the component, or autowired from the registry, is shared by all the endpoints of the component. A producer that stopped (its route stopped or removed, or Camel stopped), and with disconnect=true every request, closed it, and from then on every endpoint of the component failed its requests until the application was restarted. Camel now closes only the clients its producers create from hostAddresses. Close a client you set on the component yourself when the application no longer needs it (a client that is a Spring bean is closed by Spring).

A text field of a multipart/form-data request that occurs several times (for example a group of checkboxes) is now mapped to a header whose value is the list of all its values, as a repeated query or form-urlencoded parameter already is. Before, the header had only the first value and the others were lost. Jetty also returns the query string values of the same name, so a name that is in both the query string and a multipart text field is mapped to a list of all these values too, as it already is for a form-urlencoded request.

The servlet and Jetty consumers uncompressed a request body with Content-Encoding: gzip only when some of its bytes had already arrived when the consumer started to read it. When the client sent the body later than the headers (for example a client that sends Expect: 100-continue), the route got the compressed bytes. Such a body is now uncompressed like any other gzip request body. A route that uncompressed the body itself in that case must no longer do so. An empty body is passed on as before, and so is the body of an exchange with the CamelSkipGzipEncoding property. A request with Content-Encoding: gzip whose body is not gzip data now fails with a ZipException before the route is called (Jetty answers 500) also when the body arrives after the headers, where the route got the bytes as they were sent; it already failed in this way when the body had arrived. With disableStreamCache=true the consumer now waits for the first bytes (the GZIP header) of a gzip request body before it calls the route; with stream caching, the default, it already read the whole body before that. The same applies to every consumer that reads the request body with DefaultHttpBinding.parseBody of camel-http-common, such as the Spring Boot platform-http consumer with useStreaming=true.

The consumer now decodes the fields of an application/x-www-form-urlencoded or multipart/form-data request that declares no charset as UTF-8, the encoding browsers use. Before, Undertow’s default ISO-8859-1 was used, so café became café in the headers and the body map. A charset that the request or a part declares is still used: a client that sends ISO-8859-1 form data without declaring a charset now gets U+FFFD replacement characters instead of its text, and must declare its charset (for example application/x-www-form-urlencoded; charset=ISO-8859-1).

When the consumer lists the bucket, a failure to get one of the listed objects (for example access denied, or an archived object that is not restored) no longer fails the poll, as long as another object of that listing could be got: the object is skipped, the other listed objects are consumed, and the skipped object is tried again by a later poll. The failure is given to the exception handler of the consumer, with the key in the message (by default a WARN with the stack trace, at every poll that lists the object). Before, the poll failed, so the other objects listed with it were not consumed either, and when the bucket fitted in one listing (maxMessagesPerPoll, default 10) the consumer consumed no object at all. The poll still fails when none of the listed objects could be got. With the fileName option, a failed get still fails the poll.

The github2 consumers (commit, event, pullRequest, pullRequestComment, tag) remembered every item of a poll as consumed before routing it. Items that were not routed because the route was suspended during the poll were never routed. They are now routed by the first poll after the route is resumed.

The commit consumer also lost the new commits of a poll in which the GitHub lookup of an author or a committer failed (for example a 404 for a deleted account, or a server error). Such a commit is now routed, and a WARN is logged for it. Its CamelGitHubCommitAuthor and CamelGitHubCommitCommitter headers then have the name that git recorded in the commit instead of the name of the GitHub profile, and are not set when the commit has no name either.

When a route is suspended (RouteController.suspendRoute, also from a route policy that suspends the route such as DurationRoutePolicy, or CamelContext.suspend()) while the slack consumer routes the messages of a poll, the consumer stops after the message that is being routed. The other messages of that poll were skipped when the route was resumed. They are now kept and routed by the first poll after the resume, together with the messages posted in the meantime. They are kept in memory only: a route that is stopped and started again does not route them.

With an idempotentRepository, the mail consumer now removes the keys of the mails that a poll retrieved but did not route (the consumer was stopped in the middle of the batch, or the poll failed on a later mail), so that a later poll routes them. Before, they were skipped as duplicates by every later poll. As a consequence, a mail that the consumer cannot read (with the default skipFailedMessage=false and handleFailedMessage=false) now fails every poll until it is removed, as it does without an idempotentRepository. Before, it failed only the first poll and was then skipped, together with the mails retrieved before it. Set skipFailedMessage or handleFailedMessage to skip such a mail.

With smpps (or usingSSL=true), directly or through an HTTP proxy, the connection now checks that the certificate of the SMSC matches the host it connects to, with the same rules as an HTTPS client. Before, any certificate trusted by the JVM was accepted, whatever host it was issued for.

A connection to a host name or an IP address that the certificate does not list now fails the SSL handshake; an IP address must be listed as a subject alternative name of the certificate. Use a certificate that matches the host of the endpoint, or set the new hostnameVerification option to false to keep the previous behaviour.

A mismatch shows as the producer or consumer failing to start, with an IOException whose cause names the host that was checked:

The body of a request received by the consumer is a NettyChannelBufferStreamCache. Its read() method now returns a byte as a value from 0 to 255, and -1 at the end of the body, as java.io.InputStream requires. Before, a byte from 0x80 was returned as a negative value (0xFF as -1, which a reader takes for the end of the body), and the method threw an IndexOutOfBoundsException at the end. markSupported() now returns false (mark(int) never did anything): a reader that needs mark support has to wrap the stream, for example in a BufferedInputStream. reset() goes back to the start of the body, as before.

When securityConfiguration is set on the NettyHttpComponent, each endpoint now receives an independent copy of the configuration. Modifying securityConfiguration.* options on an endpoint URI no longer alters the component-level configuration or other endpoints.

hostnameVerification=true on a netty producer, or on a consumer with clientMode=true, now checks that the certificate of the server matches the host the endpoint connects to. Before, it made the TLS handshake fail for every certificate, matching or not, with CertificateException: Hostname or IP address is undefined - the engine was created without a peer host, so the JDK had no name to compare against.

A route that had the option set was therefore not connecting at all, and needs no change. A route that sets it while connecting to a host the certificate does not list - most commonly an IP address, which has to appear as a subject alternative name of its own - now fails the handshake with the mismatch as the reason. The default is unchanged: hostnameVerification is false, and the host is then not checked.

Enabling the option also makes the JDK send the host as an SNI server name, as camel-netty-http already did. The default path still creates the engine without a peer and sends no SNI.

On a consumer that acts as a server the option is now ignored instead of being passed to the engine. It never verified anything there - the JDK does not support host name verification on the server side of a handshake, and rejected the client certificate with Endpoint Identification Algorithm HTTPS is not supported on the server side - so a consumer that asks for client certificates and had the option set now completes the handshake instead of failing it.

When the consumer lists the bucket, a failure to get one of the listed objects (for example access denied, or an archived object that is not restored) no longer fails the poll, as long as another object of that listing could be got: the object is skipped, the other listed objects are consumed, and the skipped object is tried again by a later poll. The failure is given to the exception handler of the consumer, with the key in the message (by default a WARN with the stack trace, at every poll that lists the object). Before, the poll failed and the next poll listed the same page again, so one such object stopped the consumer from consuming any object. The poll still fails when none of the listed objects could be got, and the next poll then reads the next page of the listing.

The search operation (producer and consumer) now returns every match that the service gives. Previously it returned only the first page of the matches (the Dropbox SDK asks for 100 matches per page), and the rest was dropped without any sign. A search with many matches now sends one request per page, for the consumer at each poll. When one of these requests fails, the operation fails and no match is returned, as before.

The get operation on a folder (producer and consumer) now downloads every file of the folder. Previously it downloaded only the files of the first page of the folder listing. As before, the content of all the files is in the message body, so a large folder needs more memory than it did when only the first page was read.

When Camel creates the instance itself, the KEM operations of the pqc component (including the hybrid KEM operations) and the PQC data format now use a new KeyGenerator, and for the hybrid operations a new KeyAgreement, for every operation. A configured instance is still shared: a registry bean, which is autowired into every pqc endpoint, a KeyGenerator set on the data format, or the default material used when no key material is configured. Each operation now holds its lock from init until the result is returned, so concurrent exchanges that use it run one at a time.

A started PQC data format no longer keeps a KeyGenerator of its own: getKeyGenerator() returns only a configured instance and, unless one is configured, the CamelPQCKemAlgorithm header now selects the KEM algorithm of each operation.

The sign, verify, hybridSign and hybridVerify operations now read a java.io.File or java.nio.file.Path body, and a file from a file consumer (a GenericFile body), as bytes from the file, the same way as a byte[] or InputStream body. A String (or any CharSequence) body is encoded as UTF-8, and any other body that has a binary type converter (for example a java.nio.ByteBuffer, a java.io.ByteArrayOutputStream, a Netty ByteBuf or a Vert.x Buffer) is signed over those bytes.

A body with no binary representation (for example a Map or a POJO) is no longer signed over its toString(): it is now rejected with an InvalidPayloadException. Convert such a body to a String, byte[] or other binary type earlier in the route.

Signatures created by earlier versions over a File, Path, GenericFile or other non-byte[]/InputStream body may not verify and need to be created again.

When the consumer lists the bucket, a failure to stat or get one of the listed objects (for example access denied, or an object encrypted with a customer key the consumer does not have) no longer fails the poll, as long as another listed object could be got: the object is skipped, the other listed objects are consumed, and the skipped object is tried again by a later poll. The failure is given to the exception handler of the consumer, with the object name in the message (by default a WARN with the stack trace, at every poll that lists the object). Before, the objects listed after it in the same poll were not consumed, so one such object could keep the consumer from consuming the rest of the bucket. The poll still fails when none of the listed objects could be got, and when objectName is set. When a poll lists maxMessagesPerPoll objects, the next poll now continues after the last listed object (before, after the last object that was consumed), so an object that cannot be got at the end of a page does not hold the listing back.

The getEnterpriseEvents operation of the event-logs API now returns all the events between after and before. Previously it returned only the first chunk of the event log (at most 500 events), and the rest was dropped without any sign. A wide after/before window now returns every event in one list: that is one request per 500 events plus one that finds the end of the log, and more memory. Narrow the window when the event log is large.

A consumer that uses its own queue (queueUrl) added a target with a new random id to the EventBridge rule at every start, and removed it on stop. Two consumers that share the queue, or a restart after a consumer was not stopped cleanly, left two targets for the queue, and EventBridge put every event on the queue twice. The target now has an id derived from the queue ARN, and stays on the rule when the consumer stops, so the queue also collects the events of the rule while no consumer runs. Remove the target from the rule yourself when you no longer use the queue, and remove targets with ids camel-eb- plus 8 characters that an earlier version left for the queue. An auto-created queue is not affected. During a rolling upgrade from an earlier version, events can be put on the queue twice until the last instance on the earlier version stops.

Previously the chunk component bound the message body, headers and variables into the Chunk engine so that Chunk re-parsed those values as template source: a value that itself contained Chunk tags (such as a body of {$headers.name}) had those tags expanded instead of being printed verbatim.

Message data bound to the engine is now neutralised so that a direct {$tag} printing the body, a header, a variable, or an element of a nested map, list or array renders the value literally instead of evaluating the tags inside it. Tag-free data is unchanged and Chunk’s string filters (for example slice, get, join) keep their existing behaviour. Routes that relied on message data being evaluated as Chunk template code must move that markup into the template itself.

As part of this, a non-List Collection value (such as a Set) is now bound as a List, so a direct {$body} prints Chunk’s list placeholder instead of the collection’s toString(), and a filter such as |join operates on its elements.

This does not cover every path: Chunk re-parses any string it produces while rendering, so the output of a filter ({$body|trim}), a string property of a bean body ({$body.name}, {$exception.message}) and string items bound by a {% loop %} are still parsed as template code. Keep untrusted data to direct {$tag} output; do not pass untrusted values through Chunk filters, bean properties or loops. If untrusted data must go through one of those paths, remove the { and } characters from it in the route before the chunk endpoint (Chunk has no escape for tags inside data), for example with a processor that rewrites the body or header.

When the consumer lists the container, a failure to get one of the listed blobs (for example a blob in the archive tier, or access denied) no longer fails the poll, as long as another listed blob could be got: the blob is skipped, the other listed blobs are consumed, and the skipped blob is tried again by a later poll. The failure is given to the exception handler of the consumer, with the blob name in the message (by default a WARN with the stack trace, at every poll that lists the blob). Before, the poll failed, and as every poll lists the container again, one such blob stopped the consumer from consuming any blob. The poll still fails when none of the listed blobs could be got.

With checkpointBatchTimeout, the consumer now starts a new checkpoint window when the timer of the current window has run, and no longer when the wall clock passes the time the timer was scheduled for. Before, an event that completed in the millisecond in which the timer ran (or while the timer was taking the count) was counted in the window whose count had already been taken: it was checkpointed only with the next event, and when the partition stayed quiet it was delivered again after a restart.

The CamelAzureEventHubsCheckpointUpdatedBy header can now be timeout. An event that completes after the scheduled time of its window, but before the (late) timer has run, joins that window and gets timeout; its offset is checkpointed by that timer. Before, such an event always started a new window, so timeout was practically never set. Routes that read this header can now see timeout as well as size.

When the consumer dead-letters a message after a failed route with enableDeadLettering=true, the reason and the error description it writes are now capped at 4096 characters, the limit the Azure SDKs apply to both fields. A value that was cut ends with …​. The description holds the stack trace, so a deep one is now truncated rather than sent in full and rejected by the broker.

A settlement request the broker rejects is now reported through the consumer’s exception handler.

With jetstreamEnabled=true and a pull subscription (the default), the nats consumer kept fetching from a JetStream consumer that the server had deleted, and consumed nothing more until the route was restarted. It now subscribes again when the server no longer has its ephemeral consumer (no durableName, and no durable name in the consumerConfiguration), which the server deletes after about 5 seconds without a pull request, for example while the client is disconnected, or loses on a restart. The new consumer starts at the first message the route did not acknowledge, so the route can see again the messages after that one (with ackPolicy=None, after the last message fetched). On a stream with WorkQueue retention, and on a stream that was created again since the route subscribed, the new consumer uses the consumer configuration as it is. The consumer asks the server for its consumer only after a fetch that ended empty well before pullFetchTimeout, at most every 5 seconds. A durable consumer is not created again: when it is gone (deleted by an administrator, or after its inactiveThreshold), the consumer logs a WARN and keeps fetching, and the fetches work again when the durable is created again with the same name.

When Telegram answers a message with an error status (for example 400 for an unknown chat), or with a body that cannot be read, the producer now fails the exchange once and the route stops there. Previously the route first continued after the producer as if the message had been sent, and then the exchange failed as well.

The exception of the exchange is the one that process() of the producer threw before: a RuntimeException that wraps an ExecutionException, with the RuntimeCamelException (status and body of the answer) as its cause, or the IOException when the request got no answer. The producer still waits for the answer before it returns, so the order of the messages is the same. The steps after the producer now run on the calling thread, and no longer on a thread of the HTTP client.

With jetstreamEnabled=true and pullSubscription=false, the consumer now creates its ephemeral JetStream consumer again after a reconnect when the server deleted it, starting at the first message the route did not acknowledge, so the route can see again the messages after that one. A durable consumer is not created again (a WARN is logged), and a consumer deleted while the connection stays up is not detected. See the NATS component page for the details.

When the WebSocket of a consumer with consumeAsClient=true is closed, the consumer now makes one reconnect attempt at a time: while an attempt waits for the server (up to the connect timeout), the next runs of reconnectInterval are skipped, and maxReconnectAttempts counts these attempts one after the other. Previously every interval started another attempt, and when the server answered late each of them opened a WebSocket, so that every message was routed once per WebSocket. A consumer that is stopped no longer reconnects.

A route created from a route template or a Kamelet now returns the resource with the route template from Route.getSourceResource() (it returned null). This is the resource its source location (Route.getSourceLocation()) was already in, so the debugger and message history consoles show the source code of these routes too.

A route created from a templatedRoute also remembers the resource that declares the templatedRoute (Route.getTemplatedRouteResource(), the TemplatedRouteSource JMX attribute, and templatedRouteSource in the route dev console), and the route template id is available from Route.getRouteTemplateId(), the RouteTemplateId JMX attribute, and routeTemplateId in the route dev console.

Code that took a null source resource to mean that a route was created from a route template should use Route.isCreatedByRouteTemplate() instead.

When a route is suspended (RouteController.suspendRoute, also when a route policy calls it, or CamelContext.suspend()) while the aws2-ddbstream consumer routes the records of a poll, the consumer stops after the record that is being routed. The other records of that poll (up to maxResultsPerRequest, default 100) were skipped when the route was resumed. They are now routed after the resume. A consumer that is suspended directly (consumer.suspend()) routes all the records of its poll and was not affected.

A route with noErrorHandler runs none of its onException clauses, and a global onException is copied into every route of its route builder or file. The route structure now leaves these clauses out of such routes: the route-structure dev console, camel cmd route-structure, and the route diagrams drawn from it. Before, they were listed among the steps of the route.

A route diagram drew the onException clauses of a route among its steps, though they are not steps: a global onException is copied into every route, and runs only while a failure is handled. A route diagram now draws only the steps of the route: camel cmd route-diagram, the route-diagram dev console and its web component, and the route diagrams dumped by DumpRoutesStrategy. Use --errors (?errors=true in the dev console, the errors attribute of the <camel-route-diagram> web component, errors of DumpRoutesStrategy and @EnableRouteDiagramDump, and dumpRouteDiagramErrors of @CamelMainTest) to draw them in a frame of their own below the steps, with where the failures of the route go. A highlighted path that steps into an onException clause draws the frame as well.

The <camel-topology-diagram> web component no longer draws the error paths of the route topology as calls between routes. With its new errors attribute it draws the routes reached only on error in a frame below the other routes.

camel run --source-dir, and camel run of a directory, without --name name the integration after the directory. A folder of a project layout (src, main, resources, java, camel or routes) gives way to the first parent with another name, and . is the working directory. Before, the name was the one of the first file, in the order that the file system lists them, which could be any file, such as a Java class that a route uses. --name, and camel.main.name in application.properties, still win.

Given Java source files, camel cmd route-diagram, camel cmd route-structure and camel cmd route-topology (and the camel_render_route_diagram MCP tool) now read the routes with the Java DSL parser, as camel transform route and camel overview do, instead of compiling the sources and loading their routes in a short-lived Camel. A step the parser cannot work out, such as a lambda or a processor, is shown as a placeholder, and the parts it could not read are listed (with --json, as an unread array in the JSON). Use the new --compile option to compile the sources and load their routes as before.

camel export --runtime=quarkus wrote every quarkus. key except quarkus.hawtio. in dash case: an upper-case letter became a dash and the lower-case letter, and an underscore became a dash. That also changed the names that a key holds, such as a log category, a datasource name or a map key. Now only option names in camel case are written in dash case, such as quarkus.http.rootPath as quarkus.http.root-path. A segment of the key that is quoted, that starts with an upper-case letter, or that has no upper-case letter is kept as it is. So quarkus.log.category."com.example.MyRoute".level, quarkus.datasource.Orders.db-kind and quarkus.datasource.order_history.db-kind are no longer exported as quarkus.log.category."com.example.-my-route".level, quarkus.datasource.-orders.db-kind and quarkus.datasource.order-history.db-kind. The same applies to camel run --runtime=quarkus, which exports the project in the same way.

A name in camel case that starts with a lower-case letter, such as the datasource myOrders or my_DataSource, still looks like an option name and is written in dash case as a whole, underscores included (my-orders, my-data-source). Quote it to keep it: quarkus.datasource."myOrders".db-kind.

camel dirty counts, and camel dirty --clean removes, only the files named after the pid of a process that is gone, such as <pid>-status.json. Before, it counted every other file in ~/.camel too, and --clean removed them: the log of a Spring Boot or Quarkus app that camel run runs (<name>.log), also while the app ran, the console output that the AI tools keep, and the history of the AI prompt. Directories are not counted, and --clean counts only the files it removed.

When the consumer lists the bucket, a failure to download one of the listed objects (for example access denied, or an object whose encryption key the consumer cannot use) no longer fails the poll, as long as another listed object could be got: the object is skipped, the other listed objects are consumed, and the skipped object is tried again by a later poll. The failure is given to the exception handler of the consumer, with the object name in the message (by default a WARN with the stack trace, at every poll that lists the object). Before, the poll failed, and as every poll lists the whole bucket, one such object stopped the consumer from consuming any object. The poll still fails when none of the listed objects could be got.

With the TimeStamp (default) and PersistentTimestamp query strategies, the mongodb-gridfs consumer routed every file uploaded since the consumer started again at each poll (every delay, 500 ms by default). The upload date of the newest routed file is now kept between the polls, so a file is routed once. A route that relied on receiving the same file repeatedly now receives it once. These two strategies now skip a file whose upload date is older than that of a file already routed (as they did before Camel 3.13), for example a file from a second uploader, or from a client with another clock, that becomes visible later: GridFS sets the upload date on the client. Use TimeStampAndFileAttribute or PersistentTimestampAndFileAttribute if such files must be routed: these strategies keep the start date in their query, as before, and mark each file so that it is routed once.

A client has a single callback, and each consumer set it on its client. The consumers of several endpoints that use the same client (the client option) therefore all routed their messages through the consumer that started last, and only that consumer subscribed again after the client reconnected. The consumers of a client now share one callback: a message goes to the consumers whose topic filter matches it, also when a single consumer of the client is left (only a client that the consumer created for itself still gives it every message), and each consumer subscribes again after a reconnect. When a consumer that uses a client set with the client option stops, it now unsubscribes its topic from the client (unless cleanStart=false, or cleanSession=false for camel-paho, or another running consumer of the client uses the same topic filter), as the client stays connected, and it uses the same client again when it starts again (it created a client of its own before). This depends on the endpoint option, not on how the client was connected: set cleanStart=false on the endpoints to keep the subscriptions of a client connected with cleanStart=false. With cleanStart=false the stopped consumer’s subscription stays on the connected client, so the broker keeps sending its messages, which are dropped (with one WARN per topic, then at DEBUG) until the consumer starts again. With manualAcksEnabled=true such a dropped message is also acknowledged, so it is gone from a session that the broker keeps: left unacknowledged, it would count against receiveMaximum (for camel-paho, the broker’s limit of unacknowledged messages per client), and the broker would then send nothing more to any consumer of the client. Consumers of one client whose topic filters overlap (such as orders/# and orders/eu, or the same filter) each get a message that matches several filters, and a broker that sends one copy per matching subscription (MQTT allows it, Apache ActiveMQ Artemis does it) makes each of them get every copy. With manualAcksEnabled=true each of them acknowledges the message, so a message that failed in one of these routes is still acknowledged when another of them processes it. Each subscribe of a filter makes the broker send the retained message of a matching topic again, so consumers of the same filter get it again when another of them starts and each time they subscribe again after a reconnect. Only the running consumers count when a consumer stops: with consumers of the same filter on one client, one with cleanStart=true and one with cleanStart=false (cleanSession for camel-paho), stopping the durable one and then the other unsubscribes the filter, which also removes the subscription that the durable consumer kept. Give such consumers a client of their own.

Semantic evaluations now recognize a selected ${body} with an image Content-Type, and self-describing data:image/…​ strings, as image input. Text-only experts reject these inputs instead of treating encoded images as text. For binary image streams, Camel preserves the bytes using a replayable stream cache; downstream code must not rely on the original stream class. For the exact ${body} selector, audio/ and video/ content types now fail before inference, even for a String body. Select an explicitly textual field to evaluate text accompanying audio or video. Content-Type normalization does not apply to other selectors such as $\{bodyAs(byte[])}; use ${body} for image bytes or select a media envelope or image data URL explicitly. Ordinary strings without a media content type remain text. The $semanticInput key is reserved for explicit media envelopes. TypeSafe AI rejects that key in structured state, including nested objects; rename an application-state key that conflicts with it.

SemanticAdapter has an additive default validateState(Object) hook for validation shared by all questions for one expert. Existing per-evaluation validateInput hooks still run; both finish for every expert before any provider performs inference. A shared validation failure marks that expert’s group as invalid input in the audit.

The additive SemanticAdapter.getMaxImageBytes() method exposes an expert’s configured per-image byte limit, with zero meaning no advertised limit. Image-capable adapters should advertise a positive limit and enforce it before inference. CLI and TUI local image loading now requires that metadata; the configured value appears as maxImageBytes in each image operation’s contract.

Semantic audit backends can opt into the additive inputType extension. Readers that do not support it keep their existing projection. The camel semantic audit --json display omits image base64 and reports metadata instead. Use --output=<new-file> to export the full returned JSON, with --include-input for case/bulk requests that need captured input. Existing files are not overwritten.

When the consumer lists the file system, a failure to get one of the listed files (for example access denied by the ACL of the file) no longer fails the poll, as long as another listed file could be got: the file is skipped, the other listed files are consumed, and the skipped file is tried again by a later poll. The failure is given to the exception handler of the consumer, with the file name in the message (by default a WARN with the stack trace, at every poll that lists the file). A file deleted after the listing is skipped as well; before, it made the whole poll return no file. Before, any other failure failed the poll, and as every poll lists the file system again, one such file stopped the consumer from consuming any file. The poll still fails when none of the listed files could be got.

A milo-client consumer now delivers a data change with a Bad or Uncertain status by default, even when its value is null; previously the default omitNullValues=true dropped it. omitNullValues now only omits a null value with a Good status. A route may therefore receive a Bad status with a null value, also as the first notification of a monitored item at startup and after a reconnect, for example Bad_WaitingForInitialData or the status of a milo-server item that was not written yet. A route that uses the value must check getStatusCode() of the DataValue body first: Camel’s type converter returns 0 or false for a null value that is converted to a primitive type such as double or boolean. To skip the startup notification, filter on its status code; a filter on isGood() would also drop the Bad status of a failed sensor.

Since 4.16, a milo-client consumer whose monitored item could not be created, for example because the node does not exist, received nothing. Now it receives one DataValue with the bad status code. The monitored item is then created again every reconnectTimeout (10 seconds by default) on the same connection, without delivering anything for a failed attempt, until the server accepts it; its first value is the current value of the node. A route restart or a connection that Camel rebuilds creates it again too.

A node ID with a namespace URI (nsu=) that is not in the namespace table of the server no longer takes the whole client connection down, including the consumers of other nodes. Its consumer receives one DataValue with Bad_NodeIdUnknown, like a node that does not exist.

The consumer now sets the CamelMiloNodeId header on every exchange, including a consumer with a single node.

Stopping a consumer now deletes its monitored items. Previously they stayed on the server while another endpoint kept the shared connection open, so a restarted consumer received each value twice. While the server is unreachable, the stop waits until the client’s next attempt to reconnect has failed.

When the server removes the subscription that the consumers of a connection share, or the subscription times out on the server, it is now created again in the existing session; previously the consumers stopped receiving values until the connection was rebuilt for another reason. The monitored items deliver their current values again after the subscription is recreated.

A milo-client write, method call or read, or a milo-browse browse, for a node ID with a namespace URI (nsu=) that is not in the namespace table of the server no longer makes the client reconnect, which also recreated the subscriptions of the consumers that share the connection. A write, read or browse answers the node like a node that the server does not have, with the status code Bad_NodeIdUnknown, and the other nodes of a read or browse are not affected. Previously an awaited write or read completed without an error and with a null body, and a browse failed with a NullPointerException.

The OPC UA client consumer delivers Bad_NoCommunication with a null value for every monitored node when communication with the server is lost, and the current value of every node once communication is restored. Before, the consumer delivered nothing during an outage, and values that did not change were not delivered again after it.

A consumer that starts while the server cannot be reached, or whose client cannot connect at all, for example because of wrong credentials or an untrusted server certificate, delivers the status for its nodes too; the cause is in the log. A connection that Camel rebuilds delivers it for every node of the connection. Each loss and each recovery delivers one exchange per node.

A route that uses only the value of the DataValue body receives a null for these exchanges, which the type converters turn into 0 or false; a route that stores values checks the status code of the body first, for example with ${body.statusCode.bad}. A value can now arrive again after an outage, so a route that counts values, computes differences or detects changes must tolerate repeats. The consumer’s route also runs during an outage: an OPC UA write that it makes while the client reconnects waits for the next reconnect attempt and can take effect after communication is restored.

To keep the previous behaviour, filter the exchanges with a bad status out right after the consumer, for example with filter(simple("${body.statusCode.bad} == false")). This also drops the other bad statuses, such as the refusal of a node, and the current values delivered after an outage still arrive.

An awaited milo-client write, method call or read that fails at the service or transport level, for example a request that times out (Bad_Timeout) or a lost connection, now fails the exchange and lets the route’s error handler run. Before, the exchange completed without an error and with a null body, silently discarding the failure. A bad status for the node itself, such as Bad_TypeMismatch on a write, is not a failure of the operation and is still returned as the body.

An awaited call that succeeds now returns the CallMethodResult as the exchange body. Before, the body was always null even on success. A route that reads the result of an awaited call must be updated to read the CallMethodResult from the body instead of expecting null.

A milo-client write, method call or read, or a milo-browse browse, that fails (for example with Bad_Timeout, or because the session was lost) no longer disconnects the client connection and rebuilds the subscriptions of the consumers that share it. The failure is still set on the exchange of an awaited request. A lost session is recovered by the client itself, and a session that the server no longer has rebuilds the connection, as before. The client recovers a lost session with the endpoint and the server certificate it found when it connected, so a server that changes either while it cannot be reached is reached again only when Camel rebuilds the connection, for example when the Camel context restarts.

Producer requests and MiloClientConnection.getOpcUaClient() no longer wait for the subscription work on the same connection to finish, such as a consumer that starts or stops, or the periodic attempt to create the monitored items that the server refused. Before, they waited until the server answered that work, and while the network was down silently, until the client noticed the lost session. While Camel rebuilds the connection, a producer request now fails at once with an IllegalStateException ("No connected", caused by the failure that ended the connection) instead of waiting for the rebuild to finish. The attempts to create the refused monitored items again now run on the MiloClientReconnect thread instead of the MiloClient pool, so that a slow attempt no longer holds up the outcome of the requests, which that pool completes; on a machine with one processor the pool has a single thread.

setReconnectTimeout on the milo-client and milo-browse components set the request timeout of every service call, and the delay between two connection attempts stayed 10 seconds. It now sets that delay, which the new reconnectTimeout option of both endpoints and components sets too; its default of 10000 milliseconds is the previous delay, and a value of 0 or less is rejected. The option also sets how often the monitored items that the server refused are created again: a lower value repeats the CreateMonitoredItems request for them, for example for a node ID with a typo, more often while the connection lasts. To set the request timeout, use the requestTimeout option instead (for example camel.component.milo-client.requestTimeout, or getConfiguration().setRequestTimeout(…​) in Java).

A sessionTimeout configured on the milo-client or milo-browse component (for example camel.component.milo-client.sessionTimeout) did not reach its endpoints, so their sessions used the default of Milo, 120000 milliseconds. The endpoints now use it, unless they set sessionTimeout themselves.

The infinispan and infinispan-embedded producers now use the key option of the endpoint when it is set, and use the CamelInfinispanKey header only when the endpoint does not set key. Previously the header took precedence over the option, so a route that sent the events of an Infinispan consumer, which set CamelInfinispanKey to the key of the event, to a producer with a fixed key worked on the key of the event.

Routes that set key on the endpoint and override it per message with the CamelInfinispanKey header must remove key from the endpoint.

The CamelInfinispanCacheName header still takes precedence over the cache of the endpoint, so a route that sends the events of an Infinispan consumer to a producer must still remove the CamelInfinispan* headers first, see Key and cache name headers in the component docs.

The startQueryExecution operation of the aws2-athena producer, which is its default operation, now takes the SQL to run from the CamelAwsAthenaQueryString header, and when the header is not set, from the queryString option. It uses the message body as the SQL only when the new useMessageBodyForSql option is set to true, like the option of the same name in camel-sql. A non-empty body then takes precedence over the header and the option, as before. Previously the message body always came first, so an endpoint configured with queryString used the message body as the SQL whenever the message had one.

Routes that put the SQL in the message body, as the examples in the component documentation did, must set useMessageBodyForSql=true, or set the SQL in the CamelAwsAthenaQueryString header or the queryString option instead. Without SQL, the exchange fails with an IllegalArgumentException that names these options.

With includeTrace=true, the URI of the from endpoint in the SQL comment is now sanitized, as Camel does when it logs an endpoint URI, and it is left out when the exchange has no from endpoint, which failed with a NullPointerException before.

When a protobuf message is converted to a Map (for example getBody(Map.class) after unmarshalling), the value of a bytes field is now a byte[] with the content of the field. Previously it was the String that ByteString.toString() returns, a description such as <ByteString@1b6d3586 size=4 contents="…​">, which does not contain the whole value. When a Map is marshalled, a byte[] value is accepted for a bytes field.

Some runtime tools of the Camel MCP server now do what their description says, which changes what a client sees:

The camel_write_file and camel_edit_file tools used to refuse content with a YAML shape that a model often gets wrong but that has only one reading, such as steps: written at the column of its EIP, or an option at the column of the EIP it belongs to. Such content is now repaired and written, and repaired in the answer lists the repairs. Content with more than one reading is refused as before.

camel_edit_file now matches lines to find that are not in the file as given, as when a model writes them from memory, to the closest lines of the file when exactly one place matches well. It changes there the lines the model changed and keeps the file’s version of the other lines, and the lines of the file the model did not have. The edit stands only when its result is valid; otherwise the answer is the one of a miss, with the lines the file has there. matchedLines in the answer names the lines it matched.

A write of the content the file already has, and an edit whose replacement gives the text the file has, answer with the status unchanged instead of overwritten or edited. Nothing is written, so a running integration does not reload. When one of several edits misses, the answer shows the file as it is in fileWindow and says that none of the edits was written, also not the ones before it that matched.

camel_get_log marks the records from before the last reload of the routes with beforeLastReload, with a reloadNote first in the answer. The note of camel_get_errors on errors from before the last reload is now the first key of its answer, and says how many exchanges failed since.

camel_run and camel_control restart send the console output of the integration they start to ~/.camel/<pid>-run.log, as camel run --background does, and remove it when the integration ends. It went to ~/.camel/camel-launch-<number>.log or camel-restart-<number>.log, which stayed until the MCP server exited. An integration that still runs when the server exits keeps the file while it runs: camel stop removes it, and camel dirty --clean once the integration has ended.

With live reloading (such as camel run --dev), a change to application.properties now applies its configuration:

PropertiesReload has a new default method, onChanged, which a properties file that changed calls with the properties that changed. A context reload (such as for secret rotation) still calls onReload.

When camel run ends, its log is no longer deleted. It is kept as ~/.camel/<name>-previous.log, by the name of the integration, with ~/.camel/<name>-previous.json, which says when and how the run ended. The next run of that name that ends replaces both, and at most the last 10 MB of a log are kept. camel log <name> --previous prints the log, like kubectl logs --previous in Kubernetes. The log of an integration that was killed is kept the same way, the next time a previous run is looked up. camel dirty does not count these files.

camel-toon now uses JToon 2.0.7, which follows a newer version of the TOON specification.

The lengthMarker option of the TOON data format is removed, because the TOON specification no longer has the [N] array length marker. Remove the option from the data format in Java, XML and YAML routes. TOON text with a [#N] array header, such as the output of a data format with lengthMarker=true, now fails to unmarshal in both strict and non-strict mode; in Camel 4.23 it already failed in strict mode (the default). To read such data, remove the from its array headers (tags[#2]: becomes tags[2]:).

With strict=false, unmarshalling no longer returns null or a partial result for malformed TOON. Only the non-strict recoveries of the TOON specification apply, such as accepting an array whose length differs from the declared length; other malformed TOON fails with IllegalArgumentException, as in strict mode.

as2://server/listen consumers that share a serverPortNumber now deliver asynchronous MDNs with their own mdnUserName, mdnPassword, mdnAccessToken and asyncMdnAllowedHosts, selected by the matched requestUriPattern in the same way as the signing material. Previously the values of the first consumer configured on the port were used for every consumer on it, and the values set on the other consumers were ignored. A consumer that relied on inheriting them now has to set them itself.

This applies to asyncMdnAllowedHosts as well. A consumer without its own list used to inherit the first consumer’s list, so asynchronous MDNs to other hosts were refused; it now delivers to the address the sender gives, without credentials. A deployment that counted on the inherited list as a restriction has to set it on each consumer.

A consumer whose requestUriPattern is / now also uses its own keys, certificates and asynchronous MDN settings when another consumer created the shared server connection; before, it used the first consumer’s.

The sendNoop option now also applies to the check a consumer makes before each poll, not only to the pre-write check of a producer, and its label is now common,advanced instead of producer,advanced. The default is still true, so a consumer sends a noop before each poll as before.

A consumer endpoint that already sets sendNoop=false, which was ignored before (for example a URI shared by from and to), now skips that noop and only checks whether the client still regards itself as connected. Remove sendNoop=false from the consumer endpoint to keep the noop before each poll.

For ftp and ftps the client does not notice a connection that the server has closed, so such a consumer finds it only when the next operation fails, during the poll or while processing a file. After a failure caused by an I/O error, the consumer sends a noop before the next poll, and connects again if the noop fails. If the FTP server closes idle connections and the delay between polls is longer than its idle timeout, every other poll fails and is logged before the consumer connects again. Keep sendNoop=true for such a consumer. Whatever sendNoop is, the ftp and ftps consumer still sends a noop before it renames or deletes a file on the server, as it does for each processed file unless noop=true.

For sftp and mina-sftp the client notices a closed connection, but not one that dropped silently. For sftp the noop is a keep-alive message that does not wait for a reply, so it does not find such a connection either. For mina-sftp the noop is a request that waits for the reply, so with sendNoop=false such a connection is found by the next poll, which fails and is logged before the consumer connects again. For sftp and mina-sftp, set serverAliveInterval to let the client close such a connection itself, so that the consumer connects again before the poll.

With crossOriginFilterOn=true, the CORS responses now include Access-Control-Allow-Credentials: true only when allowedOrigins lists the origins explicitly, without any or null. When allowedOrigins is not set, is , or has an entry with a wildcard such as https://* or an entry null, the origin is still allowed, but without credentials. Previously credentials were allowed for every origin. A cross-origin client that sends cookies or other credentials must have its origin listed in allowedOrigins.

A Device producer (tahu-edge:group/edgeNode/device) no longer creates the client of its Edge Node: only the Edge Node producer creates it, from the options of the Edge Node endpoint (deviceIds, primaryHostId, servers). A Device route that starts before the Edge Node route, or while it is stopped, therefore no longer fails with a NullPointerException when the Device URI has no deviceIds. Sending to a Device endpoint while no producer of its Edge Node endpoint is started now fails the exchange with an IllegalStateException; before, the data was dropped.

The producers of aws2-ec2, aws2-ecs, aws2-eks, aws2-mq, aws2-msk, aws2-rekognition, aws2-step-functions, aws2-transcribe, aws-bedrock-agent and aws-config now fail with an IllegalArgumentException that says to set the operation option or the operation header, when neither is set. Before, they failed with a NullPointerException.

A header that holds a value of the wrong type is no longer dropped: the request is not sent, and the exchange fails with an IllegalArgumentException that names the header. This applies to CamelAwsEKSVPCConfig, CamelAwsMSKBrokerNodesGroupInfo, CamelAwsMQBrokerUsers and CamelAwsMQConfigurationID. CamelAwsMQConfigurationID also accepts the id of the configuration as a String. In aws2-ec2, CamelAwsEC2InstanceType also accepts the AWS value of the instance type (such as t2.micro), and CamelAwsEC2InstancesIds a String of ids separated by commas. In aws2-rekognition, CamelAwsRekognitionFacialAttributes and CamelAwsRekognitionDetectionAttributes also accept the names of the attributes as Strings.

In aws2-transcribe, a List in the CamelAwsTranscribeVocabularyPhrases header is now sent as one phrase per element by createVocabulary, and updateVocabulary now sends the phrases too. deleteVocabulary and deleteTranscriptionJob now set the response as the message body, as the other delete operations do.

The catalog and the endpoint DSL of aws-bedrock-agent listed the headers of aws-bedrock-agent-runtime. They now list the headers of aws-bedrock-agent, so the CamelAwsBedrockAgentRuntime* header names are no longer in the header builder of the aws-bedrock-agent endpoint DSL.

The CamelAwsEKSDescription header of aws2-eks is removed, together with the EKS2Constants.DESCRIPTION constant and its method in the header builder of the endpoint DSL. No operation of the component read it.

The aws2-mq component, which manages Amazon MQ brokers, is now in the management category instead of messaging.

In aws2-step-functions, the CamelAwsStepFunctionsExecutionInput header of startExecution and startSyncExecution must be JSON text (a String, a byte array or a stream). A value of another type, such as a Map, was sent as its toString(), which is not JSON; now the exchange fails. startSyncExecution now sets the CamelAwsStepFunctionsExecutionStatus header to the status of the execution (SUCCEEDED, FAILED or TIMED_OUT), and the CamelAwsStepFunctionsExecutionError and CamelAwsStepFunctionsExecutionCause headers when it failed. The exchange still does not fail when the execution did not succeed.

In aws-bedrock-agent, the CamelAwsBedrockAgentKnowledgeBaseId, CamelAwsBedrockAgentDataSourceId and CamelAwsBedrockAgentIngestionJobId headers now override the knowledgeBaseId, dataSourceId and ingestionJobId options, as the headers of the other AWS components do. Before, a header was used only when the option was not set.

Several data formats wrote a body they cannot handle as empty or wrong output, or returned a stream that was closed by the time the next step read it. They now behave as follows:

A multipart mail without a text part, such as one with only a PDF attachment, now converts to a String or an InputStream as null. Previously it converted to jakarta.mail.internet.MimeMultipart@…​, and the type converter then remembered that conversion, so every later multipart mail in the CamelContext converted to such a text too. A Message whose content is null also converts to null.

A text part that Jakarta Mail has no content handler for, such as text/csv or text/calendar, now converts to its text in the charset of the part. Previously it converted to the name of a stream.

When the contentType of the mail producer is text/* and gives no charset (not in the option, the header or the CamelCharsetName exchange property), the Content-Type of the sent mail now declares the charset the text is encoded in: mail.mime.charset, else the default charset of the JVM (UTF-8). The bytes sent are unchanged. Previously the Content-Type had no charset, so a reader decoded the text as US-ASCII. This also applies when ignoreUnsupportedCharset=true drops an unsupported charset.

An endpoint on imap, imaps, pop3 or pop3s used as a producer now fails when the producer is created. Previously every send failed with NoSuchProviderException: invalid provider. Use smtp or smtps to send mails.

A mail read with mapMailMessage=false can now be sent with smtp: a MimeMessage body that comes from a mail store is sent as a copy, as the messages of a store are read-only. A MimeMessage built by the route is sent as it is.

Setting the body of the message of a mail consumer, also to null, now sticks. Previously a null body gave the content of the mail again when it was read next.

After an InOut send, the message now keeps its body and the headers set before the send, and the result headers, such as CamelSmppId, are added. Previously the message had only the result headers and no body.

A CamelSmppCommand value that is not a command now fails with an IllegalArgumentException. Previously the body was sent as an SMS (SubmitSm). The names are case-sensitive, and a message without the header is still sent with SubmitSm.

SubmitSm, SubmitMulti and ReplaceSm read the body once, so a stream body is no longer sent as an empty short message. A body that is not a String or a byte[], such as a stream or a file, is replaced on the message by the value it is converted to. A message without a body fails with an SmppException caused by an InvalidPayloadException, instead of a NullPointerException.

With the dataCoding or alphabet option set to an 8-bit value, and neither the CamelSmppDataCoding nor the CamelSmppAlphabet header set, a byte[] body is now sent as it is, as with the headers. Previously its bytes were decoded as text, so bytes that are not text became ?. A text body is still encoded with the encoding option. A message whose data coding is 8-bit is now split by its length in bytes.

SmppSmCommand.getShortMessage(Message) now declares throws SmppException.

The paho and paho-mqtt5 producers now fail with an InvalidPayloadException that names the type of the body for a body that does not convert to a byte[], such as a Map, a POJO or no body. Previously they failed with a NullPointerException with no message.

The reply of a spring-rabbitmq consumer used to take the content type of the request whenever the route left the CamelSpringRabbitmqContentType header as the request set it. Now, when the route leaves the header unchanged:

A content type that the route sets is used as it is. A reply whose body is a Spring AMQP Message now gets the correlation id of the request when it has none, so the requester no longer times out.

The producer is unchanged: a route that changes the type of the body of a consumed message and sends it on should remove the CamelSpringRabbitmqContentType header.

A nats consumer with exchangePattern=InOut now answers with an empty reply when the route ends with no body. Previously it sent no reply, and the requester timed out. A body that does not convert to a byte[], such as a Map or a POJO, is still not sent, but the error now goes to the exception handler of the consumer, which logs it at WARN level.

A consumer with jetstreamEnabled=true and exchangePattern=InOut no longer publishes the reply to the ack subject of the JetStream message. InOut replies are for core NATS only, and the consumer logs a WARN when it starts.

With camel-solr on the classpath, converting a value that is not a Solr response to a java.util.Map no longer gives an empty Map. It now fails, or gives null with tryConvertTo, as without camel-solr.

Without a body:

An INSERT of a body that is not a document, such as plain text, a byte[], a stream, a number or a bean without @Field, now fails with an InvalidPayloadException also when the request has parameters. Previously it reported success and stored nothing.

The catalog now says that deleteByQuery defaults to false, as it always did at runtime. A null value in a Map body or in a CamelSolrField.* header is left out of the document, instead of failing with a NullPointerException.

An ssh endpoint with channelType=shell and no shellPrompt now fails when it starts. Previously each command failed with a NullPointerException.

sleepForShellPrompt now defaults to 100 milliseconds, as the documentation said. Previously it was 0, so the shell channel waited for the prompt in a busy loop.

The deprecated SshResult.STDERR is CamelSshStderr again. Previously it was CamelSshExitValue.

In webhook mode the slack producer now writes the JSON keys in snake_case, as Slack reads them, such as icon_emoji, icon_url, thread_ts, unfurl_links, image_url, alt_text, author_name and title_link, and short for the fields of an attachment. Previously they were written in camelCase, and Slack ignored them.

Other changes:

In token mode a SlackMessage body now sends its attachments too, not only its text.

The Slack CloudEvents data type transformer now sets CamelCloudEventSource to slack.<appId> and CamelCloudEventSubject to the channel. Previously they were slack.true and true.

The telegram producer changes:

The bufferSize option no longer limits the size of a request, so media larger than 1 MB can be sent. It is now the initial size of the buffer, and its default changed from 1048576 to 8192. The parts of a multipart request that are numbers or booleans, such as duration or disable_notification, are now sent; previously they were sent empty. The text parts are written in UTF-8, as they declare.

The spring-redis producer now fails the exchange for a CamelRedis.Command it does not run. Previously these did nothing, and the body stayed as it was:

A command in mixed case, such as Get, now runs the command. ZSCORE is now implemented and returns a Double.

The commands that read one value set the body to null when they find none, so a route can tell a miss from a value. Previously the body stayed as it was. These are GET, GETSET, HGET, LINDEX, LPOP, RPOP, BLPOP, BRPOP, RPOPLPUSH, BRPOPLPUSH, SPOP, SRANDMEMBER, RANDOMKEY, ZSCORE, ZRANK, ZREVRANK and GEODIST. For BLPOP and BRPOP, this includes when the timeout passes.

Other changes:

The consumer now gives a message that its serializer cannot deserialize, such as one published by redis-cli, to the route as a byte[]. Previously the message was dropped with a WARN. A failed exchange of the consumer is now handed to its exception handler.

The couchbase producer now uses the key option as the document id when the message has no CamelCouchbaseId header. When neither gives an id, and autoStartIdForInserts is not enabled, the call fails. Previously the document was written under the id of the Camel endpoint, such as endpoint6, and the key option was not read. The producer no longer removes the CamelCouchbaseId header after the call.

The operation option is now an enum of CCB_PUT, CCB_GET and CCB_DEL. Any other value, including one in lower case, fails when the producer starts. Previously it did nothing.

CCB_PUT now stores the body as follows:

The SQL++ query that the consumer generates when neither statement nor collection is set now reads the default collection of the bucket, FROM bucket._default._default AS bucket . Previously it failed on every poll with "Keyspace not found", as the query runs on the scope. For the same reason, an explicit statement that names the bucket in FROM fails: use the collection, such as FROM _default , or the full path.

In view mode, the rows of a reduce view and the rows with a compound key no longer fail the poll. The body of a reduce row is its value, and it has no CamelCouchbaseId header. A compound key is set in CamelCouchbaseKey as its JSON text.

With the default inputType (Hydrated for jolt, Jackson for jsonata), a body that is bytes, an InputStream (including a stream cache) or a file is now parsed as JSON, and so is text whose first non-whitespace character is { or [. Previously such a body reached the specification or expression unparsed: jolt gave null or the text back, and jsonata read the text as one JSON string, refused bytes and failed on a stream. The bytes are decoded in the charset of the exchange when one is set; otherwise the JSON parser detects the encoding. Such text that is not valid JSON now fails with the parse error. Other text, a Map, a List and other objects are used as before.

For a jsonata:http: or jsonata:https: resource, the options of the endpoint, such as inputType, outputType and prettyPrint, are now used by the endpoint. Previously they were appended to the URL of the resource and sent to the server, and the endpoint used its defaults. Only the other query parameters are sent to the server.

The xquery endpoint can only be used as a producer. A route that starts from("xquery:…​") now fails when it starts, with a message that says to use the endpoint in to. Previously it polled, and every poll failed because the query had no message to run on. The consumer and scheduler options (such as delay, initialDelay, sendEmptyMessageWhenIdle, bridgeErrorHandler and the scheduler and backoff options) are removed from the endpoint, and bridgeErrorHandler from the component.

A message without a body now fails with an InvalidPayloadException instead of a NullPointerException.

A body that is bytes, a stream or a file is given to the XML parser as bytes, so it is read in the encoding of the XML declaration (UTF-8 when there is none), unless the exchange has a charset set. A String body is read as text. Previously the body was converted to a String and encoded again in the platform charset, so a document whose declared encoding was not the platform charset could be read wrong and its validation result may now differ.

With contentCache=false, the template is now read and compiled for each exchange, so a changed template is used. Previously it was compiled once, and only the JMX operation clearContentCache read it again. The default, contentCache=true, is unchanged.

A stub endpoint that no route consumes from, such as the endpoints camel run --stub stubs, keeps the latest size messages (1000 by default) and drops the oldest one when the queue is full. Previously the producer failed with IllegalStateException: Queue full after size messages, or with blockWhenFull=true waited for a consumer that never came. The on-completions of a dropped message run as done. With a consumer, the stub endpoint queues as seda does.

Browsing a stub endpoint with a limit, such as camel cmd stub --browse --limit, now shows the latest messages. Previously the newest message was left out.

The stream:header producer now fails with a NoSuchHeaderException when the stream header is missing or is not an OutputStream. Previously it failed with a NullPointerException, or did nothing when the body was null.

The consumer now finds the content mode of a CloudEvent by the media type of the Content-Type header, ignoring its parameters and its case. A request with Content-Type: application/cloudevents+json; charset=UTF-8 is now read as a structured CloudEvent: the body is the data field and the attributes are set as the CloudEvent headers. Previously it was read as binary mode, and the body was the whole JSON envelope. A batch content type with parameters is now refused as unsupported, as the plain one is.

A producer that picks its method by a header or an option (a HeaderSelectorProducer, used by camel-caffeine, camel-consul, camel-dynamic-router, camel-ehcache, camel-infinispan, camel-servicenow, camel-spring-redis and camel-web3j) now fails the exchange with an IllegalArgumentException, such as Unsupported value NOSUCH of header CamelCaffeineAction, when no method handles the value. Previously the exchange completed with no error and the body unchanged.

The SPI InvokeOnHeaderStrategy has a new constant NO_METHOD, which the strategies generated by the Camel tooling now return for a key without a method. A strategy generated by older tooling returns null and keeps the old behaviour. The strategy of a parent class is now tried only for NO_METHOD, so a void method no longer runs the parent’s strategy too; a third-party producer with a parent class that has its own strategy must have its strategies regenerated with the 4.24 tooling.

The API components (camel-as2, camel-box, camel-braintree, camel-dhis2, camel-fhir, camel-google-calendar, camel-google-drive, camel-google-mail, camel-google-sheets, camel-olingo2, camel-olingo4, camel-twilio and camel-zendesk) now convert the message body to the type of the method parameter that inBody names, for example a byte[], a stream or a file to a String. Previously the body was passed as it was, and a body of another type failed with argument type mismatch; a body that cannot be converted now fails before the call, with an error that names the property.

A header named exactly as the prefix of an API component, such as CamelFhir or CamelFhir., is now ignored. Previously it failed every call with a StringIndexOutOfBoundsException.

The splitResult option of the google-sheets consumer now defaults to true, as documented and as the other API components do: an array or collection result gives one exchange per element. Set splitResult=false for one exchange with the whole result.

With more than 10 entries, which are sent in requests of 10, the message body is now one SendMessageBatchResponse with the successful and failed entries of all the requests. Previously the body had the entries of the last request only. An element of the body that is not a String is now converted to a String, instead of failing with a ClassCastException.

A java.nio.file.Path body is now sent as one record with the content of the file, as a java.io.File is. Previously it was sent as a batch of its name elements, which failed. A body that does not convert to a byte[] now fails with an InvalidPayloadException instead of a NullPointerException.

The headBucket and headObject operations now take the bucket from the endpoint (or the CamelAwsS3OverrideBucketName header) and the key from the keyName option (or the CamelAwsS3Key header), as the other operations do. Previously they failed without the headers.

When EventBridge rejects the event, for example with MalformedDetail for a detail that is not a JSON object, the putEvent operation now fails the exchange with a CamelExecutionException that has the error code and message. Previously only the CamelAwsEventbridgeFailedEntryCount header showed it; the header is still set. Without a body, putEvent now fails with the InvalidPayloadException itself instead of a RuntimeException. The ARNs of the CamelAwsEventbridgeResourcesArn header are now trimmed.

A binary secret that an earlier Camel version stored with binaryPayload=true holds the Base64 text of the value, and now reads back as that text, in getSecret and in the properties function. Store such secrets again, or decode the value from Base64 in the route.

The CamelAwsIAMAccessKeyStatus header now matches Active and Inactive in any case. An unknown status now fails in Camel, before the request is sent.

The aws2-ddb:application-json data type transformer now takes the operation only from the route: the CamelAwsDdbOperation header, else the operation exchange property. When the route names neither, the transformer no longer sets the CamelAwsDdbOperation header (and the CamelAwsDdbReturnValues header), so the operation option of the endpoint applies. It then sets the item, key and update values headers that PutItem, UpdateItem and DeleteItem need. Previously the transformer took the operation from a top-level operation field of the JSON body, else PutItem, and always set the header, which won over the operation of the endpoint: aws2-ddb:orders?operation=DeleteItem put the item.

A JSON body with a top-level operation field now fails with an IllegalArgumentException, unless the route names that same operation. A route that chose the operation in the body must set the header or the exchange property instead. The aws-ddb-sink Kamelet sets the exchange property, and is not affected.

The getBlob operation now writes the blob into the message body only when the body is an OutputStream. A body that only converts to one, such as a java.io.File, a java.nio.file.Path or the file of a file consumer, is replaced by an InputStream of the blob, as any other body is. Previously such a file was overwritten with the blob, also with noop=true on the file consumer. To save a blob into a file, use the downloadBlobToFile operation, or a file endpoint after getBlob.

uploadBlockBlob, uploadBlockBlobChunked and commitAppendBlob without a body now fail with an InvalidPayloadException instead of a NullPointerException, and commitAppendBlob and uploadPageBlob without a body no longer create an empty blob first.

sendMessage without a body now fails with an InvalidPayloadException, before the queue is created, instead of a NullPointerException of the Azure SDK.

The body that the consumer gives is a com.azure.core.util.BinaryData, which now converts to byte[] and InputStream as well as to String, so an unmarshal, a file producer or convertBodyTo byte[] can follow the consumer directly.

A body that is not a String or a byte[] is now converted to a byte[] first, and only a body that does not convert goes to the serializer (Java serialization by default). So a stream, a stream cache, a java.nio.file.Path and the file of a file consumer are now sent as their content, where they failed with a NotSerializableException, and a java.io.File is sent as the content of the file instead of as a serialized File object. A Map or a POJO is serialized as before, and a custom serializer is now called only for such bodies. A message without a body now fails with an InvalidPayloadException, where it published a serialized null.

putObject now takes the content length from the body when the length of the body is known (a byte[], a String, a stream cache, a file), and uses the CamelIBMCOSContentLength header only for a stream of unknown length. Previously the header won, so a route that read an object, changed the body and wrote it failed, as the header still had the length of the object it read.

The getObjectRange operation, as the catalog and the documentation name it, now works for the operation option and the CamelMinioOperation header; it failed at startup. The former name getPartialObject still works, but is deprecated.

An InputStream body, such as a stream cache, is now written to a temporary file as a byte[] body is, within maxFileSize, instead of failing with an InvalidPayloadException.

With useIterator=true (the default), the producer now splits a Jackson JSON node only when it is an array, for Jackson 2 and Jackson 3. An object node is now sent as one record; previously it was sent as one record per field value, without the field names, as the 4.22 upgrade guide said. A Jackson 3 scalar node is now sent as one record, where nothing was sent before.

dns:dig without the CamelDnsType header now asks for type A, and without the CamelDnsName header fails with an IllegalArgumentException that names the header; both failed with a NullPointerException before. The wikipedia type and the CamelDnsTerm header are deprecated, as the service behind them is gone.

The Content-Type, Accept and Accept-Encoding headers of the request are now always the ones of the producer (JSON), whatever headers the message has, and a Content-Encoding header of the message is no longer sent. The headers named by the queryHeader and variablesHeader options are no longer sent as HTTP headers. After the call the CamelHttpMethod, Accept and Accept-Encoding headers that the producer set no longer stay on the message, so a later http producer no longer sends a POST because of them. When the body is the query, a body that is not text, bytes, a stream or a file, such as a Map, now fails instead of being sent as its toString(), and a Map body (or a Map in the variables header) is used as the variables.

A java.nio.file.Path body is now sent as a file and a Reader body as its text; both failed before. The values of an application/x-www-form-urlencoded String body are now decoded before Vert.x encodes the form, so an escape such as %26 is no longer sent encoded twice, and a name that is repeated sends all its values. RAW(…​) values are no longer recognized in such a form body.

getCommitFile now takes the commit from the CamelGitHubCommitSha header, which must be a commit id of 40 hexadecimal characters, and the path of the file from the new CamelGitHubFilePath header, or else the body, and gives the content of the file at that commit. Previously the body was taken as the commit when the header was not set, and the operation could not give the content of a file.

detect and parse fail with an InvalidPayloadException for a body that does not convert to a stream, or no body, instead of a NullPointerException. parse now sets the charset of the exchange to tikaParseOutputEncoding, so the output converts to text in that charset.

The configurationUri of the component now reads a file: URI, an absolute path and property placeholders, as well as a name on the class path. The configurationUri, cacheContainer, cacheContainerConfiguration and flags options are read on the component only: set on an endpoint they are not used.

The CamelGeneratedKeysRows header is now always a List of Maps of the key columns: the outputClass and readSize options no longer apply to it. An outputClass that does not resolve fails with an IllegalArgumentException that names the class, and a message without a body fails with an InvalidPayloadException. The transacted option is deprecated, as it is not used.

With useUserKnownHostsFile=false and no knownHostsFile, scp no longer fails with a NullPointerException: no host is known, and strictHostKeyChecking decides whether to connect.

The aws-cloudtrail:application-cloudevents data type now sets the content type application/json, as the body is the JSON of the event. It was text/plain.

The python language (Jython) now gives the Java value of what a script returns, instead of its Python text from str(). None is null, a string, a number or a boolean is the Java String, number or Boolean, a dict, list, tuple or set is a Map, List or Set of Java values, and a Java object bound to the script, such as the body, is returned as it is. For example 1 + 2 gives the Integer 3 instead of the text 3, and body on a byte array gives the byte array instead of the text array('b', […​]). Set resultType to java.lang.String to get text.

This also changes predicates: None was the text None, which counted as true, and is now null, which is false. An empty list was the text [], which counted as true, and is now an empty collection, which is false.

An error while a script runs, such as a NameError, now fails with ExpressionEvaluationException instead of ExpressionIllegalSyntaxException, which is kept for a script that does not compile.

Used as an expression, for example in setBody, setHeader or setProperty, the openfeature language now gives the Boolean value of a boolean flag. Before, it evaluated every flag as a string flag, so a boolean flag gave the defaultValue of the endpoint as text (false unless set) and logged a TYPE_MISMATCH warning. String flags give their text as before, and number and object flags still give the defaultValue. Predicates are unchanged.

An expression whose result is null now gives null instead of a Document without content, unless resultType is com.datasonnet.document.Document. A predicate whose result is null is false; before, it failed with a NullPointerException.

A stream body without a body media type is now read as text. Before, it failed while the stream was mapped as a Java object.

The hl7terser language now reads a stream or a file body as an HL7 message, in the charset of MSH-18 as the HL7 data format does. A body that is not an HL7 message, such as a Map, or no body, now fails with an ExpressionEvaluationException that says what the body is, instead of a NullPointerException; text that is not a valid HL7 message fails with an ExpressionEvaluationException that has the parse error as its cause.

A Python bytes, bytearray or memoryview returned by a python3 script, and an ArrayBuffer returned by a js script, now give a byte[] instead of a List of numbers. A script that returns a function now fails with an ExpressionEvaluationException; before, it gave a value that failed when it was used later.

A JavaScript Set returned by a quickjs script now gives a List, a JavaScript Map a Map with its keys as text, and a typed array or an ArrayBuffer a List of numbers, also when nested. Before, a Set and a Map gave an empty Map, and a typed array a Map of index to value.

When the call of an API component fails, such as one of fhir, box, google-drive or twilio, the error message now names the arguments of the call, as in Error invoking resourceById with [password, resourceClass, serverUrl, stringId, username]: …​, and no longer shows their values. The arguments hold the options of the endpoint, such as a password or a token, and the message data. The debug log of the call masks the values of the sensitive options.

The solr producer now runs the operation of the CamelSolrOperation header, or else of the operation option, whatever the body is. Before, the type of the body came first: a Map, a file or a collection that is not all Strings ran an insert, and a collection of Strings ran a delete by id, even when the header or the option named another operation. The body decides only when neither is set, and a body that is a request of SolrJ, such as a SolrQuery or an UpdateRequest, still runs its own operation. The CamelSolrQueryString header makes a search only when no operation is set, and a CamelSolrOperation header with a value that is not an operation now fails.

The httpMethod option of the endpoint now wins over the CamelHttpMethod header, as its description says and as in camel-http. Before, the header overrode the option, so a route that received a request through an HTTP consumer, which sets the header to the method of that request, sent it on with that method instead of the method of the endpoint. To let the header choose the method, do not set httpMethod on the endpoint.

The server/listen and receipt/receive consumers have the new muteException option, true by default: when the route fails, the HTTP 500 that the partner gets says only that the message (or the receipt) could not be processed. Before, its body was the message of the exception of the route. Set muteException=false to send the message of the exception as before.

The CamelFileLastModified header is now the last modified time of the file, as its documentation says. Before, it was the time of the event. The header is not set when the file no longer exists, for example for a DELETE event. The time of the event is in the CamelMessageTimestamp header.