How about the JCache API? JSR 107 that is.
On 4 July 2014 11:07, Ugo Landini <ugo.land...@gmail.com> wrote: > I am interested. We could implement something similar to JSR 347 to have a > reasonably designed API > > -- uL > > Pragmatist > http://ugolandini.com > > > > On 04/lug/2014, at 15:52, Henryk Konsek <hekon...@gmail.com> wrote: > > > > Hi, > > > > Redirecting discussion [1] to the dev list. > > > >> Was also speaking with Henryk Konsek about camel-cache deprecation > >> His idea is to get camel-cache2 component to be much more generic. > > > > First of all I propose to rename camel-cache to camel-ehcache. Current > > name is too generic IMHO. Also keep ig mind that many folks use > > existing camel-cache component, so we should not deprecate it too > > eagerly. > > > > I'd like to have generic camel-cache component (named let's say > > camel-cache2 or camel-cache-api) that will provide only map-like > > interface for the cache and default in-memory implementation of the > > cache based on Camel LRU cache. Then particular components could come > > with their implementations of our generic cache interface. For > > example: > > camel-hazelcast (HazelcastCacheProvider) > > camel-guava (MapBuilderCacheProvider) > > camel-jgroups (JGroupsSharedStateCacheProvider) > > camel-ehcache (EhcacheCacheProvider) > > camel-infinispan (InfinispanCacheProvider) > > camel-spring (SpringCacheApiCacheProvider) > > ...and so forth. > > > > Cache is something that should be easily pluggable, without modifying > > client code. Anybody interesting in participating in creating > > something like camel-cache-api? > > > > Cheers. > > > > [1] > http://camel.465427.n5.nabble.com/An-idea-of-new-camel-cache-endpoint-tp5753363.html > > > > -- > > Henryk Konsek > > http://henryk-konsek.blogspot.com > -- Matt Sicker <boa...@gmail.com>
