HazelcastClientFactory can return null instead of HazelcastInstance if there is no HazelcastClient for the given name

[nosan]

Hello,

When I was working on #19669 I found that
HazelcastAutoConfiguration may create a NullBean instead of HazelcastInstance.

When HazelcastClientFactory tries to find the HazelcastInstance by name and there is no instance with that name, the null will be returned. It happens only when ClientConfig has an instance's name.

Test to reproduce:

// - HazelcastAutoConfigurationClientTests
@Test
void clientConfigWithInstanceName() {
	this.contextRunner
			.withPropertyValues("spring.hazelcast.config=classpath:org/springframework/"
					+ "boot/autoconfigure/hazelcast/hazelcast-client-instance.xml")
			.run((context) -> assertThat(context).getBean(HazelcastInstance.class)
					.extracting(HazelcastInstance::getName).isEqualTo("spring-boot"));
}

<?xml version="1.0" encoding="UTF-8"?>
<!--hazelcast-client-instance.xml-->
<hazelcast-client xmlns="http://www.hazelcast.com/schema/client-config"
				  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
				  xsi:schemaLocation="http://www.hazelcast.com/schema/client-config hazelcast-client-config-3.12.xsd">

	<instance-name>spring-boot</instance-name>
</hazelcast-client>

The test fails due to:

org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'hazelcastInstance' is expected to be of type 'com.hazelcast.core.HazelcastInstance' but was actually of type 'org.springframework.beans.factory.support.NullBean'

This issue can be fixed with a new method which was provided by Hazelcast (hazelcast/hazelcast#16362), there is also a back-port (hazelcast/hazelcast#16363), so that method should be available in Hazelcast 3.12.6

My idea is change HazelcastClient.getHazelcastClientByName(Name) to HazelcastClient. getOrCreateHazelcastClient(Config) in HazelcastClientFactory when a new version of Hazelcast will be released.

[wilkinsona]

Thanks, @nosan. What you have proposed sounds reasonable to me. WDYT, @snicoll?

[snicoll]

Dmytro and I already chatted about that offline so it's all good from my perspective. We should add a test that exercises the new behaviour as part of fixing this.

[snicoll]

Fixing this would require Hazelcast 3.12.6 as a minimum version and I am a bit nervous doing that so late in the 2.2.x cycle. I've moved the fix to 2.3.x

[snicoll]

Closing in favour of PR #20109