Factory to populate Config object from well-known locations

[jerrinot]

It allows to load config from an external file and then customize
it programmatically. This is useful when embedding Hazelcast into
managed environments: When a runtime container wants to create an
instance as if it was created via Hazelcast.newHazelcastInstance(),
but it wants to inject an instance of ManagedContext into Hazelcast
configuration.

Without this capability all containers have to duplicate the Config
location strategy: "First try this, then that, etc."

Related to spring-projects/spring-boot#19487

TODO: Tests

[jerrinot]

I realize it's VERY late in the dev cycle, so this is more for a consideration. I wonder what does Zoltan think about this change.

[jerrinot]

not a great name

[pveentjer]

I have no problem with the name. It explains that the config is loaded and this implies some files being checked. Unless you can come up with a better name, I would leave it as it is.

[jerrinot]

run-lab-run

[jerrinot]

Additional reasoning behind this change (copy and pasted from a conversation with @mmedenjak)

A runtime container typically wants to either:

1. start an instance by using programmatic configuration:
   new Config().setFoo().setBar().setManagedContext()
2. start new instance with a specific configuration file.
3. start a new instance as if it was started by Hazelcast.newHazelcastInstance(), but amend the Config with an instance of ManagedContext

#1 works without any problem, obviously.
#2 works OK-ish. You have to create either a YamlConfigBuilder or XmlConfigBuilder, Construct the Config object and then set the ManagedContext. Ideally I think we should hide the builder objects from users: Just passing a path to configuration file to a factory method on Config should be enough. The Config object can detect what file is that and create the Xml/Yaml Builder behind the scene. Maybe there is a reason to have the builders exposed. Perhaps constructing from InputStream with a config? I am not too sure.
#3 is currently complicated. You need to copy&paste the config file location strategy from Hazelcast to the container, create the instance of Config and then inject the ManagedContext. + if we change the strategy then the container code has to be changed as well. for a consistent experience.

[mmedenjak]

Does this fix #16400?

[jerrinot]

@mmedenjak it does not.

[jerrinot]

run-lab-run

[blazember]

The builders are public for the reason you mentioned: it's a flexible API letting the users to build the config from any source, mostly through the InputStream constructor.

Exposing the locator logic on a public API is a good step I believe. Since we have the convenient Config classes (FileSystemXmlConfig & co), I'd move it to something like DeclarativeConfig instead of adding it to Config directly. It could be used this way: new DeclarativeConfig().setManagedContext();.

As an additional thought, since we have convenient Config classes, it might make sense to create one for InputStreams too, so that we can make the builders private.

WDYT?

[pveentjer]

Are these empty lines required?

[pveentjer]

Can you add a note that the same mechanism is used when you call Hazelcast.newHazelcastInstance() ?

[pveentjer]

I like this API. It is simple from a user perspective. It doesn't expose anything that shouldn't be exposed.

So I give my thumbs up.

I would like to see a note that calling

HazelcastInstance hz = Hazelcast.newHazelcastInstance()

Is exactly the same as:

Config config = Config.load();
HazelcastInstance hz = Hazelcast.newHazelcastInstance(config);

[devOpsHazelcast]

All committers have signed the CLA.

[leszko]

Closing this one. I'll open a new PR with this in a moment.