oscerd opened a new pull request, #26443: URL: https://github.com/apache/camel/pull/26443
## Description `KeyValueRepositoryHelper` was added in 4.23 ([CAMEL-24463](https://issues.apache.org/jira/browse/CAMEL-24463)) to centralise the Java serialization used by the persistent `KeyValueRepository` implementations. Its `deserialize(...)` overloads created a plain `ObjectInputStream` and called `readObject()` without installing a JEP-290 `ObjectInputFilter`. That was inconsistent with the rest of the codebase. Camel already has a shared helper for exactly this — `DeserializationFilterHelper` (added in 4.22) — and every other `ObjectInputStream` call site in main source either goes through it or installs an equivalent filter, including `CassandraCamelCodec` and `JdbcCamelCodec`, the aggregation-repository counterparts of the very repositories that use this helper. Resolves [CAMEL-24725](https://issues.apache.org/jira/browse/CAMEL-24725). ## Changes **`core/camel-support`** - All four `KeyValueRepositoryHelper.deserialize(...)` overloads now install a filter resolved through `DeserializationFilterHelper.resolveDeserializationFilter(...)`: an explicitly configured pattern first, then the JVM-wide `jdk.serialFilter`, then the conservative Camel default. - Added filter-accepting overloads (`deserialize(byte[], String)`, `deserialize(byte[], int, int, String)`, `deserialize(ByteBuffer, String)`) so callers can pass a configured pattern. The existing signatures are kept and delegate with `null`. - Updated the class Javadoc, which previously asserted that the stored data is trusted. **Persistent backends** — each now exposes a `deserializationFilter` option (`@Metadata(label = "advanced,security")`) and threads it into every read, so applications that store instances of their own classes can widen the allow-list: | Module | Class | |---|---| | `camel-cassandraql` | `CassandraKeyValueRepository` | | `camel-hazelcast` | `HazelcastKeyValueRepository` | | `camel-infinispan` | `InfinispanRemoteKeyValueRepository` | | `camel-jpa` | `JpaKeyValueRepository` | | `camel-kafka` | `KafkaKeyValueRepository` | | `camel-redis` | `RedisKeyValueRepository` | | `camel-sql` | `JdbcKeyValueRepository` | The in-memory backends (`Memory`, `Caffeine`, `Ehcache`, `JCache`) keep object references and do not serialize, so they are unaffected and deliberately have no such option. **Docs** — a new *Serialization* section in `docs/user-manual/modules/ROOT/pages/key-value-repository.adoc` explains the default filter, how to widen it, and the `KeyValueAggregationRepository` case where the message body inside the stored `DefaultExchangeHolder` must also be covered. **Generated files** — bean metadata JSON, generated configurers and the catalog mirrors were regenerated. ## Behaviour note The default allow-list (`java.**`, `javax.**`, `org.apache.camel.**`, minus `java.net.**`, plus the JEP-290 graph-shape limits) is the same one the aggregation repositories have applied for several releases. Applications storing their own `Serializable` classes in a persistent `KeyValueRepository` must set `deserializationFilter` accordingly — this is the documented escape hatch and matches the existing aggregation-repository behaviour. ## Backport None required. `KeyValueRepositoryHelper` is `@since 4.23` and is not present on `camel-4.22.x` or `camel-4.18.x`, so this only needs to land on `main` before 4.23.0 is released. No upgrade-guide entry either, since the SPI has never shipped. ## Testing - `KeyValueRepositoryHelperTest` extended with six cases: the default filter rejects a denied class (`java.net.URI`), allows Java/Camel types, a custom pattern can widen and narrow the allow-list, and the filter is applied on both the offset and `ByteBuffer` variants. 28 tests pass. - Existing repository suites pass unchanged: `HazelcastKeyValueRepositoryTest` (25), `JpaKeyValueRepositoryTest` (23), `JdbcKeyValueRepositoryTest` (29), `MemoryKeyValueRepositoryTest` (27). - Built with `-Psourcecheck`; `formatter:format` and `impsort:sort` applied. --- 🤖 Generated with [Claude Code](https://claude.com/claude-code) _Claude Code on behalf of oscerd_ -- 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]
