-
Notifications
You must be signed in to change notification settings - Fork 38.8k
Closed
Labels
in: coreIssues in core modules (aop, beans, core, context, expression)Issues in core modules (aop, beans, core, context, expression)type: enhancementA general enhancementA general enhancement
Milestone
Description
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.
Metadata
Metadata
Labels
in: coreIssues in core modules (aop, beans, core, context, expression)Issues in core modules (aop, beans, core, context, expression)type: enhancementA general enhancementA general enhancement