oscerd opened a new pull request, #24588: URL: https://github.com/apache/camel/pull/24588
_Claude Code on behalf of oscerd_ JIRA: https://issues.apache.org/jira/browse/CAMEL-23815 Follow-up to the review of #24196: eight components carried their own copy of the Java-deserialization `ObjectInputFilter` default pattern and/or the `configured pattern -> JVM-wide jdk.serialFilter -> conservative Camel default` resolution logic. This PR extracts them into a single documented utility in camel-support and migrates all copies to it. ### New API (`org.apache.camel.support.DeserializationFilterHelper`) - `DEFAULT_DESERIALIZATION_FILTER` — the stream-time default (`!java.net.**;java.**;javax.**;org.apache.camel.**;maxdepth=20;maxrefs=10000;maxbytes=10485760;!*`), applied via `ObjectInputStream.setObjectInputFilter()`. - `DEFAULT_CLASS_DESERIALIZATION_FILTER` — the same allow-list **without** the JEP-290 graph-shape limits, for components that can only check the *class* of a payload a third-party library has already deserialized (JMS `ObjectMessage.getObject()`), where depth/refs/bytes metrics can never be evaluated. - `resolveDeserializationFilter(configuredPattern[, defaultPattern])` — the shared 3-step resolution. - `checkClass(filter, clazz)` — post-deserialization class check (absorbs the `FilterInfo` inner class previously duplicated in camel-jms and camel-sjms). ### On unifying the default (the question raised in the issue) The jms/sjms default deliberately omits `maxdepth`/`maxrefs`/`maxbytes`: their filter runs *after* the JMS provider has deserialized the payload, checking only the resulting class, so graph-shape limits in the pattern could never fire — including them would advertise protection that cannot be enforced. Rather than a single unified pattern, the helper keeps the two defaults side by side with javadoc explaining exactly why they differ (the "documented, deliberate per-transport choice" option from the issue). **No runtime behavior changes for any component.** The aggregation-repository/registry copies (camel-cassandraql, camel-consul, camel-leveldb, camel-sql) are intentionally untouched: they use a third, deliberately tighter pattern (no `javax.**`) exposed as a user-facing option default via `@Metadata(defaultValue = ...)`, so pointing them at a transport constant would be wrong and would only churn generated metadata. ### Migrated `camel-http-common` (HttpHelper), `camel-netty-http` (NettyHttpHelper), `camel-vertx-http` (VertxHttpHelper), `camel-jms` (JmsBinding), `camel-sjms` (JmsBinding), `camel-netty` (NettyConverter), `camel-mina` (MinaConverter), `camel-infinispan` (DefaultExchangeHolderUtils). Net -174 lines in the migrated files. ### Testing - New `DeserializationFilterHelperTest` in camel-support (11 tests): resolution order, blank-pattern handling, allow/deny round-trips through a real `ObjectInputStream`, depth-limit enforcement in stream mode, and class-check mode incl. configured-pattern override. - Existing per-module filter tests updated and passing: netty-http (6), vertx-http (6), infinispan (4), jms `JmsBindingTest` (15), sjms (7). - camel-netty and camel-mina previously only asserted the constant's contents; they now also have functional `toObjectInput` round-trips (allowed type readable, `java.net.*` rejected with `InvalidClassException`). - Full reactor `mvn clean install -DskipTests` passes; no generated files changed (no option annotations were touched). 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
