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

Spring JIRA | Chris Beams | 9 years ago
  1. 0

    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

    Spring JIRA | 9 years ago | Chris Beams
    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
  2. 0

    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

    Spring JIRA | 9 years ago | Chris Beams
    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
  3. 0

    [SPR-3946] @Autowire does not work as expected for Collections based Repository implementation - Spring JIRA

    spring.io | 1 year ago
    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 is defined: Unsatisfied dependency of type : expected at least 1 matching bean
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    [JUnit] Problem with Maven2 and cucumber-java

    Google Groups | 8 years ago | Mikael Vik
    org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [datasource.xml]: Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.<init>(Z)V
  6. 0

    Removing Data Source Connection Spring + JPA

    Stack Overflow | 3 years ago | Pelissonik
    org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'FaleConoscoWSBean': Autowiring of fields failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private br.com.embratel.faleconosco.ws.service.usuario.UsuarioService br.com.embratel.faleconosco.ws.FaleConoscoWSBean.usuarioService; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'usuarioServiceImpl': Autowiring of fields failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private br.com.embratel.faleconosco.ws.service.email.EnviarEmailService br.com.embratel.faleconosco.ws.service.usuario.UsuarioServiceImpl.enviarEmailService; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'enviarEmailServiceImpl': Autowiring of fields failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private br.com.embratel.faleconosco.ws.dao.JpaTemplateExt br.com.embratel.faleconosco.ws.service.BaseServiceImpl.jpaTemplate; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [br.com.embratel.faleconosco.ws.dao.JpaTemplateExt] is defined: Unsatisfied dependency of type [class br.com.embratel.faleconosco.ws.dao.JpaTemplateExt]: expected at least 1 matching bean

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. 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()
    2. Spring Beans
      AutowiredAnnotationBeanPostProcessor.postProcessAfterInstantiation
      1. org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessAfterInstantiation(AutowiredAnnotationBeanPostProcessor.java:208)
      1 frame