Please explain the following about NoSuchBeanDefinitionException
exception in Spring:
This post is designed to be a comprehensive Q&A about occurrences of NoSuchBeanDefinitionException
in applications using Spring.
The javadoc of NoSuchBeanDefinitionException
explains
Exception thrown when a
BeanFactory
is asked for a bean instance for which it cannot find a definition. This may point to a non-existing bean, a non-unique bean, or a manually registered singleton instance without an associated bean definition.
A BeanFactory
is basically the abstraction representing Spring's Inversion of Control container. It exposes beans internally and externally, to your application. When it cannot find or retrieve these beans, it throws a NoSuchBeanDefinitionException
.
Below are simple reasons why a BeanFactory
(or related classes) would not be able to find a bean and how you can make sure it does.
In the example below
@Configuration
public class Example {
public static void main(String[] args) throws Exception {
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(Example.class);
ctx.getBean(Foo.class);
}
}
class Foo {}
we haven't registered a bean definition for the type Foo
either through a @Bean
method, @Component
scanning, an XML definition, or any other way. The BeanFactory
managed by the AnnotationConfigApplicationContext
therefore has no indication of where to get the bean requested by getBean(Foo.class)
. The snippet above throws
Exception in thread "main" org.springframework.beans.factory.NoSuchBeanDefinitionException:
No qualifying bean of type [com.example.Foo] is defined
Similarly, the exception could have been thrown while trying to satisfy an @Autowired
dependency. For example,
@Configuration
@ComponentScan
public class Example {
public static void main(String[] args) throws Exception {
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(Example.class);
}
}
@Component
class Foo { @Autowired Bar bar; }
class Bar { }
Here, a bean definition is registered for Foo
through @ComponentScan
. But Spring knows nothing of Bar
. It therefore fails to find a corresponding bean while trying to autowire the bar
field of the Foo
bean instance. It throws (nested inside a UnsatisfiedDependencyException
)
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException:
No qualifying bean of type [com.example.Bar] found for dependency [com.example.Bar]:
expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
There are multiple ways to register bean definitions.
@Bean
method in a @Configuration
class or <bean>
in XML configuration@Component
(and its meta-annotations, eg. @Repository
) through @ComponentScan
or <context:component-scan ... />
in XMLGenericApplicationContext#registerBeanDefinition
BeanDefinitionRegistryPostProcessor
...and more.
Make sure the beans you expect are properly registered.
A common error is to register beans multiple times, ie. mixing the options above for the same type. For example, I might have
@Component
public class Foo {}
and an XML configuration with
<context:component-scan base-packages="com.example" />
<bean name="eg-different-name" class="com.example.Foo />
Such a configuration would register two beans of type Foo
, one with name foo
and another with name eg-different-name
. Make sure you're not accidentally registering more beans than you wanted. Which leads us to...
If you're using both XML and annotation-based configurations, make sure you import one from the other. XML provides
<import resource=""/>
while Java provides the @ImportResource
annotation.
There are times when you need multiple beans for the same type (or interface). For example, your application may use two databases, a MySQL instance and an Oracle one. In such a case, you'd have two DataSource
beans to manage connections to each one. For (simplified) example, the following
@Configuration
public class Example {
public static void main(String[] args) throws Exception {
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(Example.class);
System.out.println(ctx.getBean(DataSource.class));
}
@Bean(name = "mysql")
public DataSource mysql() { return new MySQL(); }
@Bean(name = "oracle")
public DataSource oracle() { return new Oracle(); }
}
interface DataSource{}
class MySQL implements DataSource {}
class Oracle implements DataSource {}
throws
Exception in thread "main" org.springframework.beans.factory.NoUniqueBeanDefinitionException:
No qualifying bean of type [com.example.DataSource] is defined:
expected single matching bean but found 2: oracle,mysql
because both beans registered through @Bean
methods satisfied the requirement of BeanFactory#getBean(Class)
, ie. they both implement DataSource
. In this example, Spring has no mechanism to differentiate or prioritize between the two. But such mechanisms exists.
You could use @Primary
(and its equivalent in XML) as described in the documentation and in this post. With this change
@Bean(name = "mysql")
@Primary
public DataSource mysql() { return new MySQL(); }
the previous snippet would not throw the exception and would instead return the mysql
bean.
You can also use @Qualifier
(and its equivalent in XML) to have more control over the bean selection process, as described in the documentation. While @Autowired
is primarily used to autowire by type, @Qualifier
lets you autowire by name. For example,
@Bean(name = "mysql")
@Qualifier(value = "main")
public DataSource mysql() { return new MySQL(); }
could now be injected as
@Qualifier("main") // or @Qualifier("mysql"), to use the bean name
private DataSource dataSource;
without issue. @Resource
is also an option.
Just as there are multiple ways to register beans, there are also multiple ways to name them.
The name of this bean, or if plural, aliases for this bean. If left unspecified the name of the bean is the name of the annotated method. If specified, the method name is ignored.
<bean>
has the id
attribute to represent the unique identifier for a bean and name
can be used to create one or more aliases illegal in an (XML) id.
@Component
and its meta annotations have value
The value may indicate a suggestion for a logical component name, to be turned into a Spring bean in case of an autodetected component.
If that's left unspecified, a bean name is automatically generated for the annotated type, typically the lower camel case version of the type name. For example MyClassName
becomes myClassName
as its bean name. Bean names are case sensitive. Also note that wrong names/capitalization typically occur in beans referred to by string like @DependsOn("my BeanName")
or XML config files.
@Qualifier
, as mentioned earlier, lets you add more aliases to a bean.
Make sure you use the right name when referring to a bean.
Bean definition profiles allow you to register beans conditionally. @Profile
, specifically,
Indicates that a component is eligible for registration when one or more specified profiles are active.
A profile is a named logical grouping that may be activated programmatically via
ConfigurableEnvironment.setActiveProfiles(java.lang.String...)
or declaratively by setting thespring.profiles.active
property as a JVM system property, as an environment variable, or as a Servlet context parameter in web.xml for web applications. Profiles may also be activated declaratively in integration tests via the@ActiveProfiles
annotation.
Consider this examples where the spring.profiles.active
property is not set.
@Configuration
@ComponentScan
public class Example {
public static void main(String[] args) throws Exception {
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(Example.class);
System.out.println(Arrays.toString(ctx.getEnvironment().getActiveProfiles()));
System.out.println(ctx.getBean(Foo.class));
}
}
@Profile(value = "StackOverflow")
@Component
class Foo {
}
This will show no active profiles and throw a NoSuchBeanDefinitionException
for a Foo
bean. Since the StackOverflow
profile wasn't active, the bean wasn't registered.
Instead, if I initialize the ApplicationContext
while registering the appropriate profile
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
ctx.getEnvironment().setActiveProfiles("StackOverflow");
ctx.register(Example.class);
ctx.refresh();
the bean is registered and can be returned/injected.
Spring uses AOP proxies a lot to implement advanced behavior. Some examples include:
@Transactional
@Cacheable
@Async
and @Scheduled
To achieve this, Spring has two options:
Take this example of JDK proxies (achieved through @EnableAsync
's default proxyTargetClass
of false
)
@Configuration
@EnableAsync
public class Example {
public static void main(String[] args) throws Exception {
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(Example.class);
System.out.println(ctx.getBean(HttpClientImpl.class).getClass());
}
}
interface HttpClient {
void doGetAsync();
}
@Component
class HttpClientImpl implements HttpClient {
@Async
public void doGetAsync() {
System.out.println(Thread.currentThread());
}
}
Here, Spring attempts to find a bean of type HttpClientImpl
which we expect to find because the type is clearly annotated with @Component
. However, instead, we get an exception
Exception in thread "main" org.springframework.beans.factory.NoSuchBeanDefinitionException:
No qualifying bean of type [com.example.HttpClientImpl] is defined
Spring wrapped the HttpClientImpl
bean and exposed it through a Proxy
object that only implements HttpClient
. So you could retrieve it with
ctx.getBean(HttpClient.class) // returns a dynamic class: com.example.$Proxy33
// or
@Autowired private HttpClient httpClient;
It's always recommended to program to interfaces. When you can't, you can tell Spring to use CGLIB proxies. For example, with @EnableAsync
, you can set proxyTargetClass
to true
. Similar annotations (EnableTransactionManagement
, etc.) have similar attributes. XML will also have equivalent configuration options.
ApplicationContext
Hierarchies - Spring MVCSpring lets you build ApplicationContext
instances with other ApplicationContext
instances as parents, using ConfigurableApplicationContext#setParent(ApplicationContext)
. A child context will have access to beans in the parent context, but the opposite is not true. This post goes into detail about when this is useful, particularly in Spring MVC.
In a typical Spring MVC application, you define two contexts: one for the entire application (the root) and one specifically for the DispatcherServlet
(routing, handler methods, controllers). You can get more details here:
It's also very well explained in the official documentation, here.
A common error in Spring MVC configurations is to declare the WebMVC configuration in the root context with @EnableWebMvc
annotated @Configuration
classes or <mvc:annotation-driven />
in XML, but the @Controller
beans in the servlet context. Since the root context cannot reach into the servlet context to find any beans, no handlers are registered and all requests fail with 404s. You won't see a NoSuchBeanDefinitionException
, but the effect is the same.
Make sure your beans are registered in the appropriate context, ie. where they can be found by the beans registered for WebMVC (HandlerMapping
, HandlerAdapter
, ViewResolver
, ExceptionResolver
, etc.). The best solution is to properly isolate beans. The DispatcherServlet
is responsible for routing and handling requests so all related beans should go into its context. The ContextLoaderListener
, which loads the root context, should initialize any beans the rest of your application needs: services, repositories, etc.
Beans of some known types are handled in special ways by Spring. For example, if you tried to inject an array of MovieCatalog
into a field
@Autowired
private MovieCatalog[] movieCatalogs;
Spring will find all beans of type MovieCatalog
, wrap them in an array, and inject that array. This is described in the Spring documentation discussing @Autowired
. Similar behavior applies to Set
, List
, and Collection
injection targets.
For a Map
injection target, Spring will also behave this way if the key type is String
. For example, if you have
@Autowired
private Map<String, MovieCatalog> movies;
Spring will find all beans of type MovieCatalog
and add them as values to a Map
, where the corresponding key will be their bean name.
As described previously, if no beans of the requested type are available, Spring will throw a NoSuchBeanDefinitionException
. Sometimes, however, you just want to declare a bean of these collection types like
@Bean
public List<Foo> fooList() {
return Arrays.asList(new Foo());
}
and inject them
@Autowired
private List<Foo> foos;
In this example, Spring would fail with a NoSuchBeanDefinitionException
because there are no Foo
beans in your context. But you didn't want a Foo
bean, you wanted a List<Foo>
bean. Before Spring 4.3, you'd have to use @Resource
For beans that are themselves defined as a collection/map or array type,
@Resource
is a fine solution, referring to the specific collection or array bean by unique name. That said, as of 4.3, collection/map and array types can be matched through Spring’s@Autowired
type matching algorithm as well, as long as the element type information is preserved in@Bean
return type signatures or collection inheritance hierarchies. In this case, qualifier values can be used to select among same-typed collections, as outlined in the previous paragraph.
This works for constructor, setter, and field injection.
@Resource
private List<Foo> foos;
// or since 4.3
public Example(@Autowired List<Foo> foos) {}
However, it will fail for @Bean
methods, ie.
@Bean
public Bar other(List<Foo> foos) {
new Bar(foos);
}
Here, Spring ignores any @Resource
or @Autowired
annotating the method, because it's a @Bean
method, and therefore can't apply the behavior described in the documentation. However, you can use Spring Expression Language (SpEL) to refer to beans by their name. In the example above, you could use
@Bean
public Bar other(@Value("#{fooList}") List<Foo> foos) {
new Bar(foos);
}
to refer to the bean named fooList
and inject that.