Auto-Wiring a List Using Util Schema Gives Nosuchbeandefinitionexception

Auto-wiring a List using util schema gives NoSuchBeanDefinitionException

This is due to a rather obscure part of @Autowired's behaviour, specified in 3.11.2. @Autowired:

It is also possible to provide all
beans of a particular type from the
ApplicationContext by adding the
annotation to a field or method that
expects an array of that type...

The same applies for typed collections...

In other words, by saying @Autowired @Qualifier("myList") List<String>, you're actually asking for "give me the list of all beans of type java.lang.String that have the qualifier "myList".

The solution is mentioned in 3.11.3. Fine-tuning annotation-based autowiring with qualifiers:

If you intend to express
annotation-driven injection by name,
do not primarily use @Autowired - even
if is technically capable of referring
to a bean name through @Qualifier
values. Instead, prefer the JSR-250
@Resource annotation which is
semantically defined to identify a
specific target component by its
unique name, with the declared type
being irrelevant for the matching
process.

As a specific consequence of this
semantic difference, beans which are
themselves defined as a collection or
map type cannot be injected via
@Autowired since type matching is not
properly applicable to them. Use
@Resource for such beans, referring to
the specific collection/map bean by
unique name.

So use this in your test, and it works fine:

@Resource(name="myList") private List<String> stringList;

Spring Autowiring a list into a bean results in a NoSuchBeanDefinitionException

Looks like some problem with generics.

With Spring 4.1 I am able to execute this code: where greatThings is of type List<Object>

@Qualifier("myList")
@Autowired List<Object> greatThings;

@Test
public void testSuperCool() {
    Assert.assertThat(greatThings, Matchers.hasSize(2));
    Assert.assertThat(greatThings, Matchers.hasItem(GreatThings.SUPER));
    Assert.assertThat(greatThings, Matchers.hasItem(GreatThings.COOL));        
}

JBoss - Autowiring list - @Resource, @Inject throws NoSuchBeanDefinitionException

I've battled with this problem a few times myself. I don't have an exact answer to your question, other than the fact that I've moved to using @Inject @Named pairs. That seems to work most of the time.

The reason @Resource doesn't work, to my knowledge, is not the fault of jboss itself, but the fault of the version of tomcat bundled by jboss.

@Autowired - No qualifying bean of type found for dependency

You should autowire interface AbstractManager instead of class MailManager. If you have different implemetations of AbstractManager you can write @Component("mailService") and then @Autowired @Qualifier("mailService") combination to autowire specific class.

This is due to the fact that Spring creates and uses proxy objects based on the interfaces.

NoSuchBeanDefinitionException while using @Configuration

@Configuration indicates that a class declares one or more @Bean methods while @Bean creates a new bean which have same name as the name of the method annotated with @Bean .

In your code sample bean with name createNewCar will be created as method createNewCar() method is annotated by @Bean.

Try this

CarBean carBean = (CarBean) context.getBean("createNewCar");
carBean.driveCar();   

Few things to look at

1. Why to annotate class CarBean as @Configuration? It dont contain any bean defination ie. method with @Bean annotation.
2. Why to invoke createNewCar() method as it is already annotated with @Bean? (Let Spring do its work)

Check this link it will help you to get familiar with @Configuration and @Bean annotation.

Wiring beans that do not implement an tag interface in list using Spring

There is another option, it helps to achieve what you try, but doesn't answer the question directly.

Spring doesn't have an exclusion mechanism like this, after all, all 4 beans are valid spring beans and are created.

However, you can work with Usable interface, instead of NotUsable marker interface. Here is a (pretty much self-explanatory) example:

interface Executor {}

interface UsableExecutor extends Executor {}

class Executor1 implements UsableExecutor{...}
class Executor2 implements UsableExecutor{...}
class Executor3 implements UsableExecutor{...}
class Executor4 implements Executor {}  // note, doesn't implement UsableExecutor

@Component
class SomeClassWithUsableExecutors {

   private final List<UsableExecutor> usableExecutors;

   // an autowired constructor - only 3 elements will be in the list 
   public SomeClassWithUsableExecutors(List<UsableExecutor> usableExecutors) {
      this.usableExecutors = usableExecutors;
   } 
}

---

Related Topics