Provide an easy way to duplicate service AutoConfiguration

[quaff]

It is higher level abstraction of #27834

Currently It's a bit hard to add extra service without back off default one, especially for RedisAutoConfiguration.

Requirement:

1. keep default service AutoConfiguration in use
2. duplicate default service with a prefix applied to beanName, configuration properties can be overriden if prefixed configuration key exists
3. mark default service bean as primary (OPTIONAL)

Possible solution:

Provide a dedicated BeanDefinitionRegistryPostProcessor to duplicate

@RequiredArgsConstructor
public class AutoConfigurationDuplicator implements BeanDefinitionRegistryPostProcessor {

	private final Class<?> autoConfigurationClass;

	private final String prefix;

	private final boolean markDefaultAsPrimary;

	@Override
	public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {

	}

	@Override
	public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException {
		// TODO duplicate all BeanDefinitions belong to autoConfigurationClass with
		// prefix, mark default BeanDefinitions as primary if markDefaultAsPrimary is true
	}

}

then duplicate service in application configuration

@Configuration
public class MyConfiguration {

	@Autowired
	@Qualifier("anotherStringRedisTemplate") // anotherStringRedisTemplate is available now
	private StringRedisTemplate anotherStringRedisTemplate; 

	@Bean
	static AutoConfigurationDuplicator anotherRedisConfiguration() {
		return new AutoConfigurationDuplicator(RedisAutoConfiguration.class, "another", false);
	}

}

spring.data.redis:
  host: redis.svc.default.cluster.local
  database: 1

another.spring.data.redis:
#  host: redis.svc.default.cluster.local default to spring.data.redis
  database: 2

[wilkinsona]

Unfortunately, the comment made on #27834 applies here too:

This is a general problem with our current design and something that we hope to address more holistically with #21322. I don’t think we’ll be able to tackle the problem in a piecemeal fashion without making things worse. We’d rather keep our existing approach of requiring manual configuration if multiple services are being used until we can find a good general purpose solution.

In other words, this is a duplicate of #21322.

[quaff]

#21322

Does #21322 require kubernetes?

[wilkinsona]

No. We expect that it will be particularly useful in a Kubernetes environment but I doubt that it will be required.

[quaff]

If #21322 is dedicated for that spec, I suggest keep this open, most people want to keep configuration properties in traditional way like this:

spring.data.redis:
  host: redis.svc.default.cluster.local
  database: 1

another.spring.data.redis:
#  host: redis.svc.default.cluster.local default to spring.data.redis
  database: 2

instead of

$SERVICE_BINDING_ROOT
├── account-database
│   ├── type
│   ├── provider
│   ├── uri
│   ├── username
│   └── password
└── transaction-event-stream
    ├── type
    ├── connection-count
    ├── uri
    ├── certificates
    └── private-key

[wilkinsona]

I don't think there's any need to do that. In addition to #21322, we also have #22403 among others. Please rest assured that this sort of functionality is on our radar.