Skip to content
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

Doc: @Configuration class accepts overloaded factory methods for same bean [SPR-13438] #18018

spring-projects-issues opened this issue Sep 7, 2015 · 1 comment
in: core Issues in core modules (aop, beans, core, context, expression) type: task A general task


Copy link

spring-projects-issues commented Sep 7, 2015

Benoit Lacelle opened SPR-13438 and commented

I do not expect a single @Configuration class accepting several beans with the same name. I guess it should follow the same contract in XML where one could not define in the same XML 2 bean with the same id.

Here is a test demonstrating the behavior. I guess there is no know knowing which bean has been accepted, and this would change from one environment to another.

package blasd.apex.server.datastore.tuple;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

@ContextConfiguration(classes = { TestSameConfDiffBeanSamename.class })
public class TestSameConfDiffBeanSamename {
	public String firstBean() {
		return "youpi";

	public Integer someBeanName(String someString) {
		return someString.length();

	public Integer someBeanName() {
		return 1;

	Integer someInteger;

	public void wonderingWhichIntegerWillArrive() {


Affects: 4.2.1

Referenced from: commits 93f77f5

Copy link
Collaborator Author

spring-projects-issues commented Sep 7, 2015

Juergen Hoeller commented

While this isn't properly documented, it is a supported feature - but not for defining multiple beans of the same name, rather just for providing various factory methods for the same bean. This is then the same algorithm as for choosing the "greediest" constructor or factory method in other configuration scenarios: Depending on the available dependencies, the variant with the largest number of satisfiable dependencies is being picked.

Compare a component class where several constructors are marked with @Autowired; several same-named @Bean methods are an analogous arrangement for factory methods. And with XML, a "factory-method" name will be resolved analogously against all declared methods of that name - the same way that a constructor will be resolved among all candidates for an XML bean definition using autowire="constructor".

Turning this issue into a documentation task, since this needs to be better documented.


@spring-projects-issues spring-projects-issues added in: core Issues in core modules (aop, beans, core, context, expression) type: task A general task labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 4.2.3 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core Issues in core modules (aop, beans, core, context, expression) type: task A general task
None yet

No branches or pull requests

2 participants