I believe there may be a need to make HazelcastClientConfiguration public or auto config.

I was creating my own auto-config class that provides a standard ClientConfig for out env:

@Configuration
@AutoConfigureBefore(HazelcastAutoConfiguration.class)
@ImportAutoConfiguration(HazelcastAutoConfiguration.class)
public class MyAutoConfiguration {

   @Bean
   @ConditionalOnMissingBean
   public ClientConfig getConfig() {
     .... return a ClientConfig
   }

}

and registered this class in the meta inf factory.

It would work on some platforms installs and in others the HazelcastClientConfiguration would not create an instance and the cache manager would go back to the default in memory cache.

Logging the debug on the broken ones, it appeared to be evaluating the hazecastautoconfig before my config despite the annotation.

I wanted to try changing the AutoConfigureBefore to the HazelcastClientConfiguration but cannot to see if that would resolve it.

Spring Boot 2.2.7

As a workaround - I made mine a standard configuration class (no auto config) - which I can do for now.

Comment From: philwebb

Have you found any consistent way to reproduce the problem? Do you know why it happens on some platforms and not others? It's pretty hard to tell if this is a bug in Spring Boot, or if there's something else going on that's environment specific.

One thing that might help is running with --debug and attaching the auto-configuration report.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: jtbdevelopment

https://github.com/jtbdevelopment/spring-hz-auto-config

I run one lib/app generating client config via normal @Configuration/@Bean and another where it is wrapped in auto configuration.

Running under Intellij on my windows 10 box - the auto config example does not initalize the client config until after hazelcast auto configuraiton

Attached some debug logs from my machine as well

Comment From: snicoll

Thanks for the sample. HazelcastClientAutoConfiguration has an explicit import on HazelcastAutoConfiguration. You don't need to import auto-configurations, each of them are registered in spring.factories (the same way you did for your own) and Spring Boot will consider them on startup based on your classpath and other conditions.

By adding an import, you are actually forcing the context to load HazelcastAutoConfiguration before your own auto-configuration is processed. This actually does the reverse of what you've expressed with @AutoConfigureBefore. I've removed the import and the app that was crashing does not crash anymore.

I am going to close this now. If I overlooked another problem, please provide more details and we can reconsider.