Consider adding a hierarchical/overridable bean resolution mechanism for auto-configurations

[grubeninspekteur]

Motivation: Given a library's auto-configuration requiring a bean of a specific type to be present in the application context, the resolution will fail if there is more than one bean present. One could annotate one of the beans as @Primary, however there are cases when you want the auto-configuration to pick up the secondary (not @Primary annotated) bean.

Suggestion: Allow providing a "scoped" or "hierarchical" bean qualification mechanism for a specific auto-configuration and/or configuration classes in a specific package, such that bean resolution works as if there was an explicit @Qualifier annotation present on all injection points.

Example SPI:

@CustomizeAutoConfiguration(for = SomeLibraryAutoconfiguration.class)
public class SomeLibraryCustomzier implements AutoConfigurationCustomizer {

    @Autowired
    @Qualifier("secondDbEntityManager")
    private EntityManager entityManager;

    @Override
    public void customizeBeanResolution(BeanResolutionCustomizer resolution) {
      resolution.forAutowiringOf(EntityManager.class).useBean(this.entityManager);
    }

}

This could also help solving issue #22403 , e.g. using something like resolution.hideExistingBean(ObjectMapper.class) on Spring's auto-configuration class that provides an ObjectMapper.

[bertondeng]

I think this will make the bean-injection mechanism a little bit sophisticated.

[grubeninspekteur]

@bertondeng Do you mean as in "too complex" / "harder to follow"?

[philwebb]

Thanks for the suggestion, but we need to consider more use-cases for #22403 before we can implement any fix. We also want to involve the Spring Framework team since we expect that changes may be required to the core.

I'll close this one for now as a duplicate of #22403