davsclaus commented on PR #26267:
URL: https://github.com/apache/camel/pull/26267#issuecomment-5624631780

   I pushed a commit to this branch (with @oscerd's permission) fixing the 
build and a few things the review surfaced:
   
   **Build** — `resolvedDeserializationFilter` was referenced but never 
declared, so `camel-jgroups` did not compile on either JDK 17 or 25. It came in 
with the caching suggestion applied in the two web-edit commits. The filter is 
now resolved once in `doStart()` (with a lazy fallback if the endpoint was not 
started), which gets the caching the suggestion was after without the data race 
on the JGroups receive threads.
   
   **The filter is now applied by default.** As written, the check only ran 
when `deserializationFilter` was explicitly set, so no existing deployment 
gained anything. That is the opposite of the rest of this work — `camel-netty`, 
`camel-mina`, `camel-jms`, `camel-spring-redis` and `CamelObjectInputStream` 
all apply a filter unconditionally and fall back to `jdk.serialFilter`, then to 
the shared Camel allow-list. camel-jgroups now does the same. 
`deserializationFilter=*` accepts any type and so opts out.
   
   **Correct default pattern** — the resolution used the single-argument 
overload, which falls back to `DEFAULT_DESERIALIZATION_FILTER` and its 
`maxdepth`/`maxrefs`/`maxbytes` limits. Those cannot be evaluated on an 
already-deserialized class, which is exactly why the helper documents 
`DEFAULT_CLASS_DESERIALIZATION_FILTER` for this case (camel-jms passes it). 
Changed accordingly.
   
   **Refusals were silent.** `CamelJGroupsReceiver.receive()` called 
`endpoint.createExchange(message)` outside its `try`/`catch`, so the 
`JGroupsException` escaped into the JGroups receive thread and was swallowed — 
I confirmed against the test log that a refused body produced no output at all, 
not even a WARN. A security control that drops messages with no audit trail is 
a problem in its own right, so the refusal now goes to the consumer's 
`ExceptionHandler` (WARN by default, and it honours `bridgeErrorHandler`).
   
   **Upgrade guide** — since the default changes, added a `camel-jgroups` entry 
to `camel-4x-upgrade-guide-4_23.adoc` alongside the camel-netty and 
camel-spring-redis ones, and documented the opt-out in the component's Security 
section.
   
   **Tests** — `JGroupsDeserializationFilterTest` now also asserts the refusal 
reaches the exception handler, and a new 
`JGroupsDefaultDeserializationFilterTest` covers the default filter refusing a 
`java.net.**` body plus `deserializationFilter=*` accepting it. All 22 tests in 
the module pass locally, formatting and generated files are up to date.
   
   _Claude Code on behalf of davsclaus_
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to