This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new c4ecbe3b6661 chore: sync main's 4.22 upgrade guide with the notes
shipping in camel-4.22.x (#26333)
c4ecbe3b6661 is described below
commit c4ecbe3b6661cfcfc1eb6c240cb65556cde5059e
Author: Claus Ibsen <[email protected]>
AuthorDate: Fri Sep 11 17:50:40 2026 +0200
chore: sync main's 4.22 upgrade guide with the notes shipping in
camel-4.22.x (#26333)
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.
Signed-off-by: Claus Ibsen <[email protected]>
Co-authored-by: Claude Opus 5 (1M context) <[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.
