Spring Invoke ConfigurationBeanNameGenerator even if a '@Bean(name = ..)' is provided

Let's assume this simple example:

@Configuration(proxyBeanMethods = false)
static class TaskExecutorConfiguration {

    @Condition1
    @Bean(TaskExecutionAutoConfiguration.APPLICATION_TASK_EXECUTOR_BEAN_NAME)
    SimpleAsyncTaskExecutor applicationTaskExecutor1() { ... }

    @ConditionNot1
    @Bean(TaskExecutionAutoConfiguration.APPLICATION_TASK_EXECUTOR_BEAN_NAME)
    ThreadPoolTaskExecutor applicationTaskExecutor2() { ... }
}

This works fine as if one is enabled, the other isn't. However, this is problematic if we want to refresh a context that needs to consider all options. In this case, the conditions aren't evaluated and the processing fails:

org.springframework.beans.factory.support.BeanDefinitionOverrideException: Invalid bean definition with name 'applicationTaskExecutor' defined in class path resource [org/springframework/boot/autoconfigure/task/TaskExecutorConfigurations$TaskExecutorConfiguration.class]: @Bean method override with same bean name but different method name: Root bean: class=null; scope=; abstract=false; lazyInit=null; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; fallback=false; factoryBeanName=org.springframework.boot.autoconfigure.task.TaskExecutorConfigurations$TaskExecutorConfiguration; factoryMethodName=applicationTaskExecutorVirtualThreads; initMethodNames=null; destroyMethodNames=[(inferred)]; defined in class path resource [org/springframework/boot/autoconfigure/task/TaskExecutorConfigurations$TaskExecutorConfiguration.class]

    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.isOverriddenByExistingDefinition(ConfigurationClassBeanDefinitionReader.java:333)
    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForBeanMethod(ConfigurationClassBeanDefinitionReader.java:222)
    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForConfigurationClass(ConfigurationClassBeanDefinitionReader.java:147)
    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitions(ConfigurationClassBeanDefinitionReader.java:123)
    at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:454)
    at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry(ConfigurationClassPostProcessor.java:306)
    at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanDefinitionRegistryPostProcessors(PostProcessorRegistrationDelegate.java:349)
    at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:118)

It would be nice if we could configure a BeanNameGenerator that always take precedence, even if @Bean has a name. This clearly is very particular for AOT processing so it doesn't need to be front and center.

Comment From: snicoll

Given that ConfigurationBeanNameGenerator has been introduced in 7.0, we could change the method to takes the method metadata and a @Nullable bean name. With that change, implementations could determine what to do if the provided bean name is not null (rather than not being called at all).

Comment From: snicoll

Juergen and I discussed and we'd like to give that option a try.

Comment From: SuganthiThomas

Hi, I’m interested in working on this issue. I have experience with Java and Spring Boot. Could I take this up?

Comment From: snicoll

Thanks for the offer but this issue is assigned so it's not open for contributions.