Add auto-configuration for Hazelcast

[snicoll]

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.

[artembilan]

Thanks, @snicoll , this sounds good!

Sorry, if I wasn't so clear in that issue with caching.

Don't forget here about Spring Cloud - see the first comment in #2848

I wonder if should just expose an option like spring.hazelcast.enable, true by default. Similar we do for JMX.

CC: @jvalkeal

[snicoll]

What should I not forget? Checking for HazelcastConfig bean?

[snicoll]

Don't forget here about Spring Cloud - see the first comment in #2848

I don't understand what you mean, sorry. Please clarify.

[artembilan]

Hello, @snicoll !

Sorry, for delay. Realy have missed this ticket somehow... Was busy outside of Hazelcast stuff 😄

Regarding Spring Cloud: I meant just keep it in mind that it is one more Spring Portfolio projects which uses Hazelcast and Boot. Although, as we see by their code, it does that wrong way - without any @Conditionals. And my point here is to fix that code when we will have this HazelcastAutoConfiguration already.
CC @jvalkeal

What should I not forget? Checking for HazelcastConfig bean?

Yes, I think so. Something similar what you do in the HazelcastCacheConfiguration but for common auto-config exposing it as a conditional bean and that cache abstraction (@AutoConfigureAfter ?) can reuse the config:

@Autowired(required = false)
private Config hazelcastConfig;

The instance may look like this:

@Bean
@ConditionalOnMissingBean
public HazelcastInstance hazelcastInstance(Config hazelcastConfig) {
    if (StringUtils.hasText(config.getInstanceName())) {
        return Hazelcast.getOrCreateHazelcastInstance(cfg);
    }
    return Hazelcast.newHazelcastInstance(cfg);
}

and so on.

[snicoll]

okay so checking for the presence of HazelcastInstance or Config is what I was looking for. Thanks.

[shakuzen]

👍 for this enhancement. And if possible (though I know the release date for RC1 is quickly approaching), I'd love to see this in 1.3.

[shakuzen]

@snicoll Would it be worth opening a separate issue for basic Hazelcast auto-configuration? I mostly just want to use it with Spring Session and possibly as an in-memory data grid. This seems to be a more basic requirement than supporting Spring Integration. Then perhaps that could be included in 1.3 (I would be willing to work on a PR), while the SI parts wait until 1.4?

[snicoll]

@shakuzen I've already started and this issue has no SI bits at all. The purpose was to allow SI to smoothly integrate with it. In other words, this issue is the "basic" requirement you're mentioning.

It would be nice if you could try it once it's done so that we get a chance to improve it if necessary.