use the hazelcast Config.loadConfig() which in turn calls Config.applyEnvAndSystemVariableOverrides() to override the loaded config with environment variables (which is the default behavior when starting a hazelcast without spring boot auto-configuration)
Comment From: pivotal-cla
@luben93 Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.
Comment From: pivotal-cla
@luben93 Thank you for signing the Contributor License Agreement!
Comment From: wilkinsona
Thanks for the proposal. I'm not sure that this should be considered a bug. I can't recall the details, but the code's been this way since the auto-configuration was introduced and it may well be intentional. Even if we did consider it to be a bug, changing it is not without risk as it may be a breaking change if things are now overridden that weren't previously. I'll flag this for team attention so that we can consider our options.
Comment From: luben93
Perhaps not a bug but it's very counter intuitive in regards to the hazelcast documentation that states that you should be able to override with environment variables, but when using autoconfigure with spring.hazelcast.config set that just stops to work
Comment From: luben93
If the spring.hazelcast.config is not set Config.load() is called instead and that does enable the overriding
Comment From: wilkinsona
Well spotted. Thanks, @luben93. As I understand it now, setting spring.hazelcast.config to one of Hazelcast's default locations will result in the configuration being loaded without overriding. Removing the setting will result in the configuration being loaded from the same location but this time with overriding enabled. I doubt that this subtle difference in behavior is intentional so I think we should consider this to be a bug. Now we just need to decide which version to fix it in. There is still a small chance that fixing it may be a breaking change.
Comment From: philwebb
We discussed this today and we think that this should be considered as a bug, but it's quite risky for us to fix it in a patch release. As such, we'll change the code in Spring Boot 3.1 and recommend that folks use the work-around if they are on earlier versions.
Comment From: wilkinsona
The workaround is to define a Config bean, loaded using the preferred mechanism.
Comment From: mhalbritter
Thanks and congrats to your first Spring Boot contribution!