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 f02cde41ea67 CAMEL-24676: Sync the camel-jgroups 4.22.1 upgrade guide 
entry to main (#26282)
f02cde41ea67 is described below

commit f02cde41ea679f8a3582b639b0ddd99ab723b4f0
Author: Claus Ibsen <[email protected]>
AuthorDate: Fri Sep 11 08:10:12 2026 +0200

    CAMEL-24676: Sync the camel-jgroups 4.22.1 upgrade guide entry to main 
(#26282)
    
    * CAMEL-24676: Sync the camel-jgroups 4.22.1 upgrade guide entry to main
    
    The camel-jgroups deserialization filter was backported to camel-4.22.x in 
#26281,
    which added an upgrade guide entry for that release line to
    camel-4x-upgrade-guide-4_22.adoc on the maintenance branch.
    
    The camel-4x-upgrade-guide-4_XX.adoc files on main are the canonical 
history across
    all releases, so the same entry is added here. Without it main's 4.22 
upgrade guide
    drifts out of sync with what actually ships on camel-4.22.x.
    
    Doc-only, verbatim copy of the entry on the maintenance branch.
    
    Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
    Signed-off-by: Claus Ibsen <[email protected]>
    
    * CAMEL-24676: Move the upgrade guide entry into the 4.22.0 to 4.22.1 
section
    
    camel-4x-upgrade-guide-4_22.adoc is ordered newest section first, so 
appending to
    the end of the file put the entry in the "Upgrading Camel 4.21 to 4.22" 
section,
    describing a change that does not ship in 4.22.0.
    
    Moved to the end of the "Upgrading from 4.22.0 to 4.22.1" section, matching 
the
    placement on camel-4.22.x. Text is unchanged and verified identical to the 
entry
    on the maintenance branch.
    
    Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
    Signed-off-by: Claus Ibsen <[email protected]>
    
    ---------
    
    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    | 26 ++++++++++++++++++++++
 1 file changed, 26 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 b7d7948545c2..f5fd9ae5243a 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
@@ -177,6 +177,32 @@ custom `headerFilterStrategy` is used as-is and is 
unaffected.
 Routes that relied on one of those headers reaching the wire must set it 
through the endpoint
 configuration or supply a `headerFilterStrategy` that permits it.
 
+
+=== camel-jgroups - the consumer applies a deserialization filter by default
+
+The consumer maps an incoming cluster message to the exchange body by calling
+`org.jgroups.Message.getObject()`, which Java-deserializes the payload. The 
class of that body is
+now checked against a JEP-290 `java.io.ObjectInputFilter`, resolved through
+`DeserializationFilterHelper`. Previously no filter was applied at all, and 
any type a cluster peer
+sent was routed.
+
+When no explicit pattern is configured, the JVM-wide `jdk.serialFilter` is 
honoured if set,
+otherwise the shared Camel default allow-list is applied (it permits standard 
Java and Apache Camel
+types and denies `java.net.**`). Routes that exchange their own classes over 
the cluster must widen
+it through the new `deserializationFilter` endpoint option, for example:
+
+[source,java]
+----
+from("jgroups:clusterName?deserializationFilter=com.example.model.**;java.**;!*")
+----
+
+Setting `deserializationFilter=*` accepts any type and so restores the 
previous behavior. A refused
+message is not routed; it is reported to the consumer's `ExceptionHandler`, 
which logs it at WARN
+level by default.
+
+Note that JGroups deserializes the payload inside its own receive path, so 
this check is a
+defense-in-depth allow-list on the resulting body type. The JVM-wide 
`jdk.serialFilter`, together
+with a channel secured with `AUTH` and encryption, remain the primary 
mitigations.
 == Upgrading Camel 4.21 to 4.22
 
 === camel-tika

Reply via email to