This is an automated email from the ASF dual-hosted git repository. davsclaus pushed a commit to branch quick-fix/sync-4_22-upgrade-guide in repository https://gitbox.apache.org/repos/asf/camel.git
commit c2db6af035967aa8f365fc092ac6f622d46e8b31 Author: Claus Ibsen <[email protected]> AuthorDate: Fri Sep 11 15:24:16 2026 +0200 chore: sync main's 4.22 upgrade guide with the notes shipping in camel-4.22.x The version-specific upgrade guides on main are the canonical history across all release lines, but five entries added by backports to camel-4.22.x were never added to main's camel-4x-upgrade-guide-4_22.adoc. Each exists on main only in the 4.23 guide, so a user upgrading to a 4.22.x patch release could not find it. Copied verbatim from camel-4x-upgrade-guide-4_22.adoc on camel-4.22.x: - camel-support - BackgroundTask.schedule cancels its repeating schedule - camel-master - backOffMaxAttempts bounds the delegate start attempts - camel-servlet, camel-jetty - fileNameExtWhitelist is enforced against the submitted file name (backport #26320, merged as part of this sweep) - camel-tensorflow-serving - the Target and Credentials headers are deprecated - camel-hazelcast - ReplicatedHazelcastAggregationRepository applies the default serialization filter Documentation only. Co-authored-by: Claude Opus 5 (1M context) <[email protected]> Signed-off-by: Claus Ibsen <[email protected]> --- .../ROOT/pages/camel-4x-upgrade-guide-4_22.adoc | 73 ++++++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc index 0c199bb62d31..c8c256ffd439 100644 --- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc +++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc @@ -1979,3 +1979,76 @@ When `clientRequestValidation` is enabled and the REST service declares a requir message body is no longer replaced with a `String` version of itself. That conversion corrupted binary payloads such as `application/octet-stream`. The body is still read to check that it is present, using stream caching so it stays re-readable, but it now keeps its original type. + +=== camel-support + +`BackgroundTask.schedule` now cancels the repeating schedule it created once the task has completed or has +run out of budget. Previously the returned `Future` stayed armed and the task kept being re-run as a no-op +for the lifetime of the executor. Callers that inspect the returned `Future` will see `isCancelled()` +return `true` after the task is done, where it previously stayed live. Callers that already cancel the +`Future` themselves are unaffected. + +=== camel-master + +The `backOffMaxAttempts` option now bounds the attempts to start the delegated consumer as documented. +The retry task previously also carried the default five second duration of its budget, which ended the +task before the second attempt for any `backOffDelay` at or above the default of five seconds. A delegate +that fails to start is therefore retried for longer than before, up to `backOffMaxAttempts` times. + +=== camel-servlet, camel-jetty - the multipart upload whitelist is enforced against the submitted file name + +`fileNameExtWhitelist` accepts file name extensions, but `camel-servlet`'s `AttachmentHttpBinding` +checked it against `Part.getName()`, which is the multipart *field* name rather than the submitted +file name. A field named `file` carries no extension, so the check found nothing to compare and every +upload was accepted. The option is now checked against `Part.getSubmittedFileName()`, which is what +`camel-platform-http-vertx` already does. + +A `camel-servlet` consumer that sets `fileNameExtWhitelist` together with `attachmentMultipartBinding=true` +therefore starts rejecting uploads whose file extension is not listed, which is what the option always +advertised. Uploads with no file name, such as plain form fields, are unaffected, and a route that does +not set the option is unaffected. Review the configured extension list before upgrading. + +The `camel-jetty` binding performed no whitelist check at all, although `fileNameExtWhitelist` can be +set on its `HttpBinding`. It now applies the same check. + +The `camel-jetty` binding also stored the attachment under the multipart field name but looked it up +again by the submitted file name, and passed that file name to `HttpHelper.appendHeader`. The lookup +therefore only succeeded when the two happened to be equal, and when it did the header was named by +the client-supplied file name. The attachment is now looked up and exposed under the field name it is +stored with, and only for parts that carry a file name — a plain form field is mapped by +`populateRequestParameters` as before. Because the old lookup by file name returned `null` whenever the +two names differed, that header never carried a usable `DataHandler` in the first place; only when the +names happened to be equal did it resolve, and then the name is unchanged. A route that expected the +attachment header under the uploaded file name should read it under the multipart field name. + +=== camel-tensorflow-serving - the Target and Credentials headers are deprecated + +`TensorFlowServingConstants.TARGET` (`CamelTensorFlowServingTarget`) and +`TensorFlowServingConstants.CREDENTIALS` (`CamelTensorFlowServingCredentials`) are deprecated. Both +were declared with `@Metadata` and advertised through the endpoint's `headersClass`, but neither has +ever been read by the component. + +The gRPC channel and its stubs are built once in `TensorFlowServingEndpoint.doInit()` from +`configuration.getTarget()` and `configuration.getCredentials()`, so a per-exchange override supplied +as a header cannot take effect. A route that set either header was silently ignored. The sibling +`camel-kserve` component declares neither. + +Configure the `target` and `credentials` endpoint options instead, or route to a different endpoint +with `toD` when the destination varies per message. The constants remain in place for backwards +compatibility and are now marked deprecated in the component metadata. + +=== camel-hazelcast - ReplicatedHazelcastAggregationRepository now applies the default serialization filter + +`ReplicatedHazelcastAggregationRepository` now applies the same default +`JavaSerializationFilterConfig` that the other repositories and the component endpoints have applied +since 4.14.8/4.18.3/4.21.0, when it bootstraps its own `HazelcastInstance` (that is, when no +`hazelcastInstance` is supplied). It overrides `doStart()` without calling `super.doStart()` and was +therefore left out of that change. + +The default whitelists the class name prefixes `java.`, `javax.`, `org.apache.camel.` and blacklists +`java.net.`, and a user-supplied `JavaSerializationFilterConfig` is still respected and never +overwritten. + +Applications that aggregate classes outside the default whitelist through the replicated repository +without supplying their own `hazelcastInstance` must now provide a `Config` with a +`JavaSerializationFilterConfig` covering their class names.
