gnodet commented on PR #22158: URL: https://github.com/apache/camel/pull/22158#issuecomment-5250921511
Thanks for the thoughtful feedback from @Croway, @oscerd, and @orpiske on the overlap question. I've updated the PR description with a detailed section addressing this, but let me summarize the key points here: ### Why a new component instead of reusing existing ones The existing Camel components (caffeine-cache, infinispan, spring-redis) are **technology-specific** — they expose the full API of each product (queries, pub/sub, statistics, events, etc.). That's their strength, but it's also their overhead when you just need `store(key, value)` / `retrieve(key)`. **The primary motivation is MuleSoft migration.** MuleSoft's Object Store is a core primitive that MuleSoft users rely on heavily. When migrating MuleSoft flows to Camel, there's no direct equivalent — users are forced to pick a technology (Caffeine? Redis? Infinispan?) and learn its full component API, when all they need is a simple key-value store. ### What the backend modules do (and don't do) The backend modules (`camel-state-store-caffeine`, etc.) are **thin adapters** — they implement the `StateStoreBackend` interface using each technology's native client library directly. They don't duplicate or wrap the existing Camel components. Think of it like how `camel-jms` has its own `ConnectionFactory` setup rather than wrapping `camel-activemq`. ### This follows established Camel patterns - `camel-sql` / `camel-jdbc` vs vendor-specific SQL components - `camel-jms` vs `camel-activemq`, `camel-amqp` - `camel-jcache` (JSR-107) vs `camel-caffeine-cache`, `camel-ehcache` ### Regarding @orpiske's point about medium-term vision I agree that a broader discussion about stateful operations in Camel would be valuable (and CAMEL-11114 "Create cache DSL" is related). This component is designed to be compatible with a future direction: the `StateStoreBackend` interface is currently scoped to the component module, but could be promoted to `camel-api` if a core cache DSL/EIP emerges. I've pushed an update addressing all the code-level review feedback (rebased, squashed, versions fixed, Thread.sleep → Awaitility, AssertJ, @since tags, FQCN fixes). Happy to discuss the architectural direction further. _Claude Code on behalf of Guillaume Nodet_ -- 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]
