Croway commented on PR #2046: URL: https://github.com/apache/camel-spring-boot/pull/2046#issuecomment-6262675892
Follow-up on the design question above: I opened apache/camel#28086 ([CAMEL-25791](https://issues.apache.org/jira/browse/CAMEL-25791)), which adds a small extension point to the State Store component: - a `StateStoreBackendFactory` functional interface: `KeyValueRepository createBackend(String storeName)` - an **autowired** `backendFactory` component option, so a single bean of that type in the registry is picked up automatically - resolution order: explicit endpoint `backend` → factory (once per store name, started and stopped by the component) → single registry `KeyValueRepository` → in-memory Once that is merged (targeting 4.24.0), this PR could register a factory instead of a global `KeyValueRepository`: ```java @AutoConfiguration(afterName = "org.springframework.boot.cache.autoconfigure.CacheAutoConfiguration") @ConditionalOnClass({ CacheManager.class, StateStoreBackendFactory.class }) @ConditionalOnProperty(prefix = "camel.spring.cache.state-store", name = "enabled", havingValue = "true") public class SpringCacheStateStoreAutoConfiguration { @Bean @ConditionalOnMissingBean(StateStoreBackendFactory.class) @ConditionalOnSingleCandidate(CacheManager.class) public StateStoreBackendFactory springCacheStateStoreBackendFactory(CacheManager cacheManager) { return storeName -> new SpringCacheKeyValueRepository(cacheManager, storeName); } } ``` This would: - give the 1:1 `storeName` → Spring cache mapping described in CAMEL-24757 (`state-store:myStore` → `cacheManager.getCache("myStore")`), so the JIRA example works and stores no longer collide (finding 5) - leave Aggregate, Idempotent Consumer and Cache EIP untouched, because they only auto-discover `KeyValueRepository` beans. That removes findings 1, 2 and 4: no `optimisticLocking()` breakage, no `completionTimeout` startup failure, and no silently dropped Cache EIP TTL - fix finding 3 via `@ConditionalOnSingleCandidate` - remove the need for the hard-coded `camel-kvr` cache and the `cache-names` caveat in the docs Since the code then depends on `camel-state-store`, `components-starter/camel-state-store-starter` might be a better home than `core/camel-spring-boot`. That way the core module doesn't need a new dependency, and the feature is only active when the state-store component is on the classpath. Users who still want the Spring cache for an EIP can pass a `SpringCacheKeyValueRepository` to it explicitly. That's a deliberate opt-in rather than a side effect of a global bean. The Redis IT request from the previous comment still applies. _Claude Code on behalf of Federico Mariani_ -- 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]
