This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

When I start my application server, I get a NoSuchBeanDefinitionException. Through debugging, I found that ReflectionUtils.getAllDeclaredMethods(FordFactory) returns an array that contains three versions of getInstance():

public FordCar FordFactory.getInstance()

public java.lang.Object FordFactory.getInstance()

public java.lang.Object CarFactory.getInstance()

The first is correct, attached to FordFactory and returning FordCar. The other two both return Object, one attached to FordFactory and the other attached to CarFactory. Because between the three methods, two different return types are found, Spring throws up its hands and declares that the type of the bean can't be determined.

Is the behavior of a bean factory extending a generic abstract class not allowed? Why wouldn't the factory method just be called to instantiate a new bean, letting the type be determined by reflection on the instance rather than on the return type of the method?

Explicitly noting the type of the bean in the bean definition XML doesn't help. Removing the abstract parent classes removes the extra two method references (the ones returning Object) returned by ReflectionUtils, allowing the bean to instantiate. But this isn't ideal, since I structured my classes that way for a reason.