@Configuration
@ComponentScan("com.baeldung.packageA")
public class ContextWithJavaConfig {
If beans are not automatically scanned but instead defined manually, then BeanB is simply not defined in the current Spring Context.
3. Cause: Field […] in […] Required a Bean of Type […] That Could Not Be Found
In a Spring Boot application for the above scenario, we get a different message.
Let’s take the same example where BeanB is wired in BeanA, but it’s not defined:
@Component
public class BeanA {
    @Autowired
    private BeanB dependency;
    //...
If we try to run this simple application, that tries to load BeanA:
@SpringBootApplication
public class NoSuchBeanDefinitionDemoApp {
    public static void main(String[] args) {
        SpringApplication.run(NoSuchBeanDefinitionDemoApp.class, args);
The application will fail to start with this error message:

***************************
APPLICATION FAILED TO START
***************************
Description:
Field dependency in com.baeldung.springbootmvc.nosuchbeandefinitionexception.BeanA required a bean of type 'com.baeldung.springbootmvc.nosuchbeandefinitionexception.BeanB' that could not be found.
Action:
Consider defining a bean of type 'com.baeldung.springbootmvc.nosuchbeandefinitionexception.BeanB' in your configuration.
Here com.baeldung.springbootmvc.nosuchbeandefinitionexception is the package for BeanA, BeanB and NoSuchBeanDefinitionDemoApp.
The snippet for this example can be found in this GitHub project.
4. 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.
Let’s say an interface IBeanB is implemented by two beans, BeanB1 and BeanB2:
@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:
@Component
public class BeanA {
    @Autowired
    private IBeanB dependency;
And again, this will result in a NoSuchBeanDefinitionException being thrown by the BeanFactory:
Caused by: org.springframework.beans.factory.NoUniqueBeanDefinitionException: 
No qualifying bean of type 
  [com.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.
However, notice that in this case the exact exception being thrown is not NoSuchBeanDefinitionException but a subclass: the NoUniqueBeanDefinitionException. This new exception was introduced in Spring 3.2.1 for exactly this reason — to differentiate between the cause where no bean definition was found and where several definitions are found in the context.

Before this change, this was the above exception:
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: 
No qualifying bean of type [com.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:
@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).
5. Cause: No Bean Named […] Is Defined
A NoSuchBeanDefinitionException may also be thrown when a bean that isn’t defined is requested by name from the Spring context:
@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:
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.
6. Cause: Proxied Beans
When a bean in the context is proxied using the JDK Dynamic Proxy mechanism, the proxy will not extend the target bean (but it will implement the same interfaces).
Because of this, if the bean is injected by an interface, it will be correctly wired in. However, if the bean is injected by the actual class, 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:
@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 okay:
@Service
@Transactional
public class ServiceA implements IServiceA{
    @Autowired
    private IServiceB serviceB;
@Service
@Transactional
public class ServiceB implements IServiceB{
7. Conclusion
This article discussed examples of the possible causes for the common NoSuchBeanDefinitionException — 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.
Finally, the full list of exceptions and solutions in Spring might be a good resource to bookmark.
Partner – Microsoft – NPI EA (cat=Java)

Microsoft JDConf 2024 conference is getting closer, on March
27th and 28th. Simply put, it's a free virtual event to
learn about the newest developments in Java, Cloud, and AI.
Josh Long and Mark Heckler are kicking things off in the
keynote, so it's definitely going to be both highly useful and
quite practical.
For the full conference agenda and speaker lineup, you can
explore JDConf.com:
RSVP Now

Partner – Payara – NPI EA (cat=Jakarta EE)


Can Jakarta EE be used to develop microservices? The answer is a
resounding ‘yes’!
Demystifying Microservices for Jakarta EE & Java EE
Developers

Partner – Aegik AB – NPI EA (tag = SQL)


Slow MySQL query performance is all too common. Of course
it is.
The Jet Profiler was built entirely for MySQL, so it's
fine-tuned for it and does advanced everything with relaly minimal
impact and no server changes.
out the Profiler

Partner – Codium – NPI EA (cat = Testing)


Explore the secure, reliable, and high-performance Test
Execution Cloud built for scale. Right in your IDE:
CodiumAI. Meaningful Code Tests for Busy Devs

Basically, write code that works the way you meant it to.
Partner – Machinet – NPI EA (cat = Testing)


AI is all the rage these days, but for very good reason. The
highly practical coding companion, you'll get the power of
AI-assisted coding and automated unit test generation.

Machinet's Unit Test AI Agent utilizes your own project
context to create meaningful unit tests that intelligently aligns
with the behavior of the code.

Simplify Your Coding Journey with Machinet AI:
>> Install Machinet
AI in your IntelliJ
Course – LS (cat=Spring)

Get started with Spring and Spring Boot, through the Learn Spring course:
>> THE COURSE
res – REST with Spring (eBook) (everywhere)

Learning to build your API

with Spring?
Download the E-book