org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'com.foo.MyTests': Autowiring of fields failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.foo.domain.PersonRepository com.foo.MyTests.personRepository; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [com.foo.domain.Person] is defined: Unsatisfied dependency of type [com.foo.domain.Person]: expected at least 1 matching bean

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • Consider the following Repository artifacts: public interface PersonRepository extends Set<Person> {} final class JdoPersonRepository extends AbstractSet<Person> implements PersonRepository { // ... implementation omitted } And the test that excercises them: @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration public class PersonRepositoryTests { @Autowired private PersonRepository personRepository; // test methods omitted... } } And finally, the named-by-convention beans XML used by the test (PersonRepositoryTests-context.xml): <beans ...> <bean id="pmf" class="org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean"> <property name="configLocation" value="classpath:jpox.properties"/> </bean> <bean id="pmfProxy" class="org.springframework.orm.jdo.TransactionAwarePersistenceManagerFactoryProxy"> <property name="targetPersistenceManagerFactory" ref="pmf" /> <property name="allowCreate" value="false" /> </bean> <bean id="personRepository" class="com.foo.domain.JdoPersonRepository"> <constructor-arg ref="pmfProxy"/> </bean> <bean id="transactionManager" class="org.springframework.orm.jdo.JdoTransactionManager"> <property name="persistenceManagerFactory" ref="pmf"/> </bean> <tx:annotation-driven/> </beans> Expected behavior when running the test: 1) Spring bootstraps an ApplicationContext backed by PersonRepositoryTests-context.xml 2) The @Autowired 'personRepository' dependency is detected within my PersonRepositoryTests class 3) Spring looks up this resource by type and injects it directly at the field level, with no further ado. Actual behavior when running the test: Steps (1) and (2) execute as expected. Step (3) however, gets more complicated. Because java.util.Collection is assignable from PersonRepository, the logic in AbstractAutowireCapableBeanFactory (fisheye: http://tinyurl.com/2utx6u) assumes that I want my JdoPersonRepository bean to be autowired with beans of its generic collection parameter type (which is Person in this case). Furthermore it fails upon being unable to locate at least one such Person beans in the container. Relevant excepts from the resulting stack trace follow: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'com.foo.MyTests': Autowiring of fields failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.foo.domain.PersonRepository com.foo.MyTests.personRepository; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [com.foo.domain.Person] is defined: Unsatisfied dependency of type [com.foo.domain.Person]: expected at least 1 matching bean at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessAfterInstantiation(AutowiredAnnotationBeanPostProcessor.java:208) ... Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [com.foo.domain.Person] is defined: Unsatisfied dependency of type [com.foo.domain.Person]: expected at least 1 matching bean at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveDependency(AbstractAutowireCapableBeanFactory.java:373) Suffice to say this behavior is not what I want or expect to happen. But, as the issue type of 'Improvement' suggests, I don't know that I can call this a 'bug' either. I can see that the original design intent is being fulfilled; it's just that I have a use case for which that design causes problems. Could we conceive a way to (configurably) relax this assumption that Collection-based beans must have one or more element beans declared in the container? Also note, this issue is somewhat related to SPR-3668, where I encountered a similar problem with the container attempting to call size() on beans assignable to Collection. Juergen relaxed this behavior, and I'm hoping we can do the same here. (see especially his comment on the issue: http://opensource.atlassian.com/projects/spring/browse/SPR-3668#action_24701) I do have a workaround in the meantime: instead of declaring my dependency by interface: @Autowired private PersonRepository personRepository; I'm now declaring by concrete type: @Autowired private JdoPersonRepository personRepository; This bypasses the '&& type.isInterface()' condition (see fisheye link above), and allows the bean to simply be returned and injected without further complication. At any rate, thanks for looking into this. - Chris Beams
    via by Chris Beams,
  • Consider the following Repository artifacts: public interface PersonRepository extends Set<Person> {} final class JdoPersonRepository extends AbstractSet<Person> implements PersonRepository { // ... implementation omitted } And the test that excercises them: @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration public class PersonRepositoryTests { @Autowired private PersonRepository personRepository; // test methods omitted... } } And finally, the named-by-convention beans XML used by the test (PersonRepositoryTests-context.xml): <beans ...> <bean id="pmf" class="org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean"> <property name="configLocation" value="classpath:jpox.properties"/> </bean> <bean id="pmfProxy" class="org.springframework.orm.jdo.TransactionAwarePersistenceManagerFactoryProxy"> <property name="targetPersistenceManagerFactory" ref="pmf" /> <property name="allowCreate" value="false" /> </bean> <bean id="personRepository" class="com.foo.domain.JdoPersonRepository"> <constructor-arg ref="pmfProxy"/> </bean> <bean id="transactionManager" class="org.springframework.orm.jdo.JdoTransactionManager"> <property name="persistenceManagerFactory" ref="pmf"/> </bean> <tx:annotation-driven/> </beans> Expected behavior when running the test: 1) Spring bootstraps an ApplicationContext backed by PersonRepositoryTests-context.xml 2) The @Autowired 'personRepository' dependency is detected within my PersonRepositoryTests class 3) Spring looks up this resource by type and injects it directly at the field level, with no further ado. Actual behavior when running the test: Steps (1) and (2) execute as expected. Step (3) however, gets more complicated. Because java.util.Collection is assignable from PersonRepository, the logic in AbstractAutowireCapableBeanFactory (fisheye: http://tinyurl.com/2utx6u) assumes that I want my JdoPersonRepository bean to be autowired with beans of its generic collection parameter type (which is Person in this case). Furthermore it fails upon being unable to locate at least one such Person beans in the container. Relevant excepts from the resulting stack trace follow: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'com.foo.MyTests': Autowiring of fields failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.foo.domain.PersonRepository com.foo.MyTests.personRepository; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [com.foo.domain.Person] is defined: Unsatisfied dependency of type [com.foo.domain.Person]: expected at least 1 matching bean at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessAfterInstantiation(AutowiredAnnotationBeanPostProcessor.java:208) ... Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [com.foo.domain.Person] is defined: Unsatisfied dependency of type [com.foo.domain.Person]: expected at least 1 matching bean at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveDependency(AbstractAutowireCapableBeanFactory.java:373) Suffice to say this behavior is not what I want or expect to happen. But, as the issue type of 'Improvement' suggests, I don't know that I can call this a 'bug' either. I can see that the original design intent is being fulfilled; it's just that I have a use case for which that design causes problems. Could we conceive a way to (configurably) relax this assumption that Collection-based beans must have one or more element beans declared in the container? Also note, this issue is somewhat related to SPR-3668, where I encountered a similar problem with the container attempting to call size() on beans assignable to Collection. Juergen relaxed this behavior, and I'm hoping we can do the same here. (see especially his comment on the issue: http://opensource.atlassian.com/projects/spring/browse/SPR-3668#action_24701) I do have a workaround in the meantime: instead of declaring my dependency by interface: @Autowired private PersonRepository personRepository; I'm now declaring by concrete type: @Autowired private JdoPersonRepository personRepository; This bypasses the '&& type.isInterface()' condition (see fisheye link above), and allows the bean to simply be returned and injected without further complication. At any rate, thanks for looking into this. - Chris Beams
    via by Chris Beams,
  • Autowiring of fields failed exception
    via Stack Overflow by user
    ,
    • org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'com.foo.MyTests': Autowiring of fields failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.foo.domain.PersonRepository com.foo.MyTests.personRepository; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [com.foo.domain.Person] is defined: Unsatisfied dependency of type [com.foo.domain.Person]: expected at least 1 matching bean at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessAfterInstantiation(AutowiredAnnotationBeanPostProcessor.java:208)

    Users with the same issue

    Unknown visitor1 times, last one,
    Unknown visitor1 times, last one,