Spring Better exception for bean that doesn't match due to signature [SPR-15868]

Caleb Cushing opened SPR-15868 and commented

given this

@Configuration
public class LuceneRepositoryConfiguration {

    private final boolean test;

    public LuceneRepositoryConfiguration( @Value( "#{environment.acceptsProfiles('test')}" ) boolean test ) {
        this.test = test;
    }

    @Bean
    public LuceneSpecificationExecutor<ProviderTest> providerTestLuceneRepository() {
        return new LuceneRepository<>( ProviderTest.class, test );
    }
}

and this constructor injection

public ZCodeDetailTestsOfferedViewModel(
        IPrincipalService principalService,
        ProviderTestRepository providerTestRepository,
        LuceneRepository<ProviderTest> providerTestLuceneRepository,
        IProviderTestService providerTestService,
        ObjectFactory<Instant> now ) {
    this.principalService = principalService;
    this.providerTestRepository = providerTestRepository;
    this.providerTestLuceneRepository = providerTestLuceneRepository;
    this.providerTestService = providerTestService;
    this.now = now;
}

I get this exception

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.mckesson.dex.repository.lucene.LuceneRepository<com.mckesson.dex.model.procedure.ProviderTest>' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1493)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1104)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1066)
    at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:835)
    at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:741)
    ... 44 more

now I agree this shouldn't work, but I'm wondering if it would be possible to find out that concrete class exists as a bean in the context, but has returned a different signature, and instead say "signature mismatch" or "type mismatch" with better information. If it's not possible or would be too expensive I can accept that.

---

No further details from SPR-15868

Comment From: snicoll

but I'm wondering if it would be possible to find out that concrete class exists as a bean in the context, but has returned a different signature,

If it was, then we would happily inject the bean and not fail at all. Bean definitions must expose the most specific target type as, once the bean is instantiated, the context can honor any signature that matches so it's not like you'd be hiding the real implementation this way anyway.