It is higher level abstraction of https://github.com/spring-projects/spring-boot/issues/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

Comment From: 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.

Comment From: quaff

21322

Does #21322 require kubernetes?

Comment From: wilkinsona

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

Comment From: quaff

If https://github.com/spring-projects/spring-boot/issues/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

Comment From: wilkinsona

I don't think there's any need to do that. In addition to #21322, we also have https://github.com/spring-projects/spring-boot/issues/22403 among others. Please rest assured that this sort of functionality is on our radar.