1. Overview
In this article, we are discussing the Springorg.springframework.beans.factory.NoSuchBeanDefinitionException – this is a common exception thrown by the BeanFactory when trying to resolve a bean that simply isn’t defined in the Spring Context.
We will discuss here the possible causes for this problem and the available solutions.
2. Cause: No qualifying bean of type [...] found for dependency
The most common cause of this exception is simply trying to inject a bean that isn’t defined. For example – BeanB is wiring in a collaborator – BeanA:
|
1
2
3
4
5
6
7
|
@Component
public
class
BeanA {
@Autowired
private
BeanB dependency;
...
}
|
Now, if the dependency – BeanB – is not defined in the Spring Context, the bootstrap process will fail with the no such bean definition exception:
|
1
2
3
4
|
org.springframework.beans.factory.NoSuchBeanDefinitionException:
No qualifying bean of
type
[org.baeldung.packageB.BeanB] found
for
dependency:
expected at least 1 bean
which
qualifies as autowire candidate
for
this dependency.
Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=
true
)}
|
The reason is clearly indicated by Spring: “expected at least 1 bean which qualifies as autowire candidate for this dependency“
One reason BeanB may not exist in the context – if beans are picked up automatically byclasspath scanning, and if BeanB is correctly annotated as a bean (@Component,@Repository, @Service, @Controller, etc) – is that it may be defined in a package that is not scanned by Spring:
|
1
2
3
|
package
org.baeldung.packageB;
@Component
public
class
BeanB { ...}
|
While the classpath scanning may be configured as follows:
|
1
2
3
4
5
|
@Configuration
@ComponentScan
(
"org.baeldung.packageA"
)
public
class
ContextWithJavaConfig {
...
}
|
If beans are not automatically scanned by instead defined manually, then BeanB is simply not defined in the current Spring Context.
3. Cause: No qualifying bean of type [...] is defined
Another cause for the exception is the existence of two bean definitions in the context, instead of one. For example, if an interface – IBeanB is implemented by two beans –BeanB1 and BeanB2:
|
1
2
3
4
5
6
7
8
|
@Component
public
class
BeanB1
implements
IBeanB {
//
}
@Component
public
class
BeanB2
implements
IBeanB {
//
}
|
Now, if BeanA autowires this interface, Spring will not know which one of the two implementations to inject:
|
1
2
3
4
5
6
7
|
@Component
public
class
BeanA {
@Autowired
private
IBeanB dependency;
...
}
|
And again, this will result in a NoSuchBeanDefinitionException being thrown by theBeanFactory:
|
1
2
3
|
Caused by: org.springframework.beans.factory.NoUniqueBeanDefinitionException:
No qualifying bean of
type
[org.baeldung.packageB.IBeanB] is defined:
expected single matching bean but found 2: beanB1,beanB2
|
Similarly, Spring clearly indicates the reason for the wiring failure: “expected single matching bean but found 2″.
Notice however, that in this case, the exact exception being thrown is notNoSuchBeanDefinitionException but a subclass – theNoUniqueBeanDefinitionException. This new exception has been introduced in Spring 3.2.1, for exactly this reason – to differentiate between the cause where no bean definition was found and this one – where several definitions are found in the context.
Before this change, the exception above was:
|
1
2
3
|
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException:
No qualifying bean of
type
[org.baeldung.packageB.IBeanB] is defined:
expected single matching bean but found 2: beanB1,beanB2
|
One solution to this problem is to use the @Qualifier annotation to specify exactly the name of the bean we want to wire:
|
1
2
3
4
5
6
7
8
|
@Component
public
class
BeanA {
@Autowired
@Qualifier
(
"beanB2"
)
private
IBeanB dependency;
...
}
|
Now Spring has enough information to make the decision of which bean to inject –BeanB1 or BeanB2 (the default name of BeanB2 is beanB2).
4. Cause: No Bean Named [...] is defined
A NoSuchBeanDefinitionException may also be thrown when a bean that isn’t defined isrequested by name from the Spring context:
|
1
2
3
4
5
6
7
8
9
10
11
|
@Component
public
class
BeanA
implements
InitializingBean {
@Autowired
private
ApplicationContext context;
@Override
public
void
afterPropertiesSet() {
context.getBean(
"someBeanName"
);
}
}
|
In this case, there is no bean definition for “someBeanName” – leading to the following exception:
|
1
2
|
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException:
No bean named
'someBeanName'
is defined
|
Again, Spring clearly and concisely indicates the reason for the failure: “No bean named X is defined“.
5. Cause: Proxied Beans
When a bean in the context is proxied using the JDK Dynamic Proxy mechanism, then the proxy will not extend the target bean (it will however implement the same interfaces).
Because of this, if the bean is injected by an interface, it will be correctly wired in. If however the bean is injected by the actual class, then Spring will not find a bean definition that matches the class – since the proxy does not actually extend the class.
A very common reason the bean may be proxied is the Spring transactional support – namely beans that are annotated with @Transactional.
For example, if ServiceA injects ServiceB, and both services are transactional, injecting by the class definition will not work:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
@Service
@Transactional
public
class
ServiceA
implements
IServiceA{
@Autowired
private
ServiceB serviceB;
...
}
@Service
@Transactional
public
class
ServiceB
implements
IServiceB{
...
}
|
The same two services, this time correctly injecting by the interface, will be OK:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
@Service
@Transactional
public
class
ServiceA
implements
IServiceA{
@Autowired
private
IServiceB serviceB;
...
}
@Service
@Transactional
public
class
ServiceB
implements
IServiceB{
...
}
|
6. Conclusion
This tutorial discussed examples of the possible causes for the commonNoSuchBeanDefinitionException – with a focus on how to address these exceptions in practice.
The implementation of all these exceptions examples can be found in the github project – this is an Eclipse based project, so it should be easy to import and run as it is.
原文地址：http://www.baeldung.com/spring-nosuchbeandefinitionexception
http://blog.csdn.net/free4294/article/details/38706569
http://stackoverflow.com/questions/31199888/spring-task-scheduler-no-qualifying-bean-of-type-org-springframework-scheduli
