-
Notifications
You must be signed in to change notification settings - Fork 38.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overloaded @Bean method with name mismatch causes bean to be created twice (in case of ASM processing) #25263
Comments
hello,I think you might need to provide a demo,Because I don't know the relationship between the two,Thanks. |
@lifejwang11 not sure exactly what you mean by "the relationship between the two". If you're talking about the two beans But anyway, here's a complete demo if you want to try it by yourself: https://github.com/jnizet/spring-overload-issue |
If I execute the following test against @SpringJUnitConfig
class SomeConfigTests {
@Test
void test() {
}
@Configuration
static class SomeConfig {
@Bean(name = "other")
public SomeOtherBean foo() {
System.out.println("constructing SomeOtherBean");
return new SomeOtherBean();
}
@Bean(name = "foo")
public SomeBean foo(@Qualifier("other") SomeOtherBean other) {
System.out.println("constructing SomeBean");
return new SomeBean(other);
}
}
} The output is:
And the output is the same for the Though, I can confirm that the output from your sample Spring Boot application is the following.
|
The unit test isn't functionally equivalent to the sample as you have removed component scanning from the equation. The sample application still reproduces the problem when modified to remove any use of Spring Boot: package com.example.demo;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.ComponentScan;
@ComponentScan
public class DemoApplication {
public static void main(String[] args) {
new AnnotationConfigApplicationContext(DemoApplication.class);
}
} |
Tentatively slated for 5.3 M2 for further investigation |
I think the key to this question is AbstractAutowireCapableBeanFactory#getTypeForFactoryMethod
If you have two methods with the same name and bean annotation in the same class,I think you need to determine if beanName is the same,so I think this code should be modified in ConfigurationClassBeanDefinitionReader#isFactoryMethod old
new
If my idea is right, I would like to submit a PR,thanks |
@sbrannen The bug I think Methods with @bean should not only determine if the method name is the same, but also if the name attribute corresponding to the bean annotation of the method (or the default method name without the name attribute) is the same as the current method name,I think the way to do bean annotation is like this, don't you think |
…er bean not to be created spring-projects#25263
in spring framework 5.2.8 also exist this issue |
I've tracked this down to a difference between Class-based processing of the configuration class versus ASM-based processing against a registered configuration class name. A variant of the unit test passes with Class registration (similar to the |
Reproduced in Spring 5.2.7.RELEASE (Spring Boot 2.3.1.RELEASE):
With the above configuration class,
SomeOtherBean
is constructed twice, andSomeBean
is never constructed. Why? Because the two methods have the same name. If you rename the second method tobar
, everything is constructed once, as expected.Admittedly, using the same method name is not a good idea. I just happened to have done it by accident.
The text was updated successfully, but these errors were encountered: