Description
This was the original intent of #2848 but unfortunately the actual discussion moved to another direction.
Hazelcast can be used for "non-caching" scenario. In particular, spring-integration
has a specific Hazelcast integration. This integration needs the HazelcastInstance
as a @Bean
definition and it does not need to be necessarily coupled with caching. So it should work even if HazelcastCacheManager
is not present and if @EnableCaching
has not been specified.
This brings some interesting use cases:
- Use Hazelcast for SI channels and "Foo" for caching
- Use Hazelcast for SI channels and Hazelcast for caching
- Only using Hazelcast for SI channels or only use Hazelcast for caching
Since HazelcastInstance
provides cache-related features and other features, we would need to move the processing to a dedicated auto-configuration. We should probably integrate the caching-related bits in there if need to be (i.e. HazelcastAutoConfiguration
has a dependency to the caching support, i.e. CachingProperties
).
spring.cache.config
should probably move away to spring.cache.hazelcast.config
, spring.cache.ehcache.config
and spring.cache.jcache.config
and a new spring.hazelcast.config
should be created. The mere presences of two separate properties would allow to create two HazelcastInstance
if need to be. The condition to figure that out won't be easy to implement though.
Remains one last issue related to JCache. If we use Hazelcast
and JCache
for caching with hazelcast behind the scenes, we may bootstrap two HazelcastInstance
while the user may expect the same configuration to be used with a single instance. Not sure yet if that's a problem and how to handle it.