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-issuemaster opened this issue Sep 7, 2015 · 1 comment


None yet
2 participants
Copy link

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


This comment has been minimized.

Copy link
Collaborator Author

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.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.