1. Overview
While working on Spring Boot projects, we might face a situation where there is a requirement to disable autowiring of beans. In this tutorial, we’ll learn how to disable autowiring for beans in Spring Boot applications through some use cases.
2. Disable Autowiring
First, let’s clarify that disabling autowiring of beans means that when the Spring Boot app starts, it won’t try to create beans for a specific class. Generally, we use @Component annotation on a class to let Spring create its beans and @Autowired to inject that bean into the declared field.
Now, when can this situation arise? Let’s discuss two use cases.
2.1. In Our Source Code
One of the core tasks of Spring is to maintain the beans for us. It creates, maintains, and destroys without any major effort from our side. But there could be a situation where we have a class and don’t want a bean of this class to be created while booting up. Scenarios that could lead to this situation are circular dependencies, lazy loading, multi-profile environments, or when managing prototype/request-scoped beans to avoid unnecessary initialization and improve performance.
Using the @Autowired annotation on a variable makes Spring inject a bean of that type. It’s a mandatory step, but there are situations where we don’t want to autowire some beans at startup. To achieve this, we can simply use @Autowired(required = false). By doing this, we are telling Spring not to autowire this variable – just ignore it.
2.2. While Using Third-Party Libs
Let’s understand the second use case. Suppose we’re using a third-party library, and we need to create a bean of a class. But there is a catch! The Bean class uses an internal dependency, and we don’t want to autowire it. Also, we can’t modify their code since it’s a third-party library.
Let’s consider the code below:
@Component
public class TestBean {
@Autowired
private TestDependency dependency;
...
}
This class, TestBean, exists in a third-party library, and we want to create a bean for it, but we don’t want to create a bean for TestDependency. Now, we have our use case!
Generally, the first instinct is to use @Bean annotation as given below:
@Bean
public TestBean testBean() {
return Library.createBean();
}
If we test this one by using a test case:
@Autowired
private ApplicationContext applicationContext;
@Test
void whenTestBeanIsCraetedWithBeanAnnotation_thenItShouldFail() {
TestBean testBean = applicationContext.getBean(TestBean.class);
Assertions.assertNotNull(testBean);
}
It’ll fail to run successfully, giving an exception No qualifying bean of type ‘TestDependency’ available: expected at least 1 bean which qualifies as autowire candidate.
So, how do we solve this?
The solution to this problem is to create a bean by using the FactoryBean class.
3. FactoryBean
Factory Bean is a bean that acts as a factory for creating other beans and instantiating them with the Spring IOC container.
This approach is useful in complex object creation scenarios, making it difficult to define using simple XML or annotation-based configuration. It’s often employed for creating proxy instances, such as AOP proxies, where dynamic behavior needs to be added to objects.
Additionally, it plays a key role in integrating third-party libraries that require custom initialization logic, which is our second use case.
It provides fine-grained control over bean instantiation, such as managing smart caching or determining whether the created bean should follow a singleton scope.
Let’s see how to implement the FactoryBean interface. Let’s understand how to do it in simple way for TestBean:
public class TestBeanFactoryBean implements FactoryBean<TestBean> {
@Override
public TestBean getObject() throws Exception {
return new TestBean();
}
@Override
public Class<?> getObjectType() {
return TestBean.class;
}
@Override
public boolean isSingleton() {
return true;
}
}
So, in the above code, we’re providing logic to create a bean in the getObject() method, specifying the type in the getObjectType() class and scope by isSingleton() method. We’ve control over bean creation by using these methods.
Now, let’s understand how this will help us solve our problem:
public static <T> FactoryBean<T> createBean(T bean) {
return new FactoryBean<T>() {
public T getObject() throws Exception {
return bean;
}
public Class<?> getObjectType() {
return bean.getClass();
}
public boolean isSingleton() {
return true;
}
};
}
@Bean
static FactoryBean<TestBean> testBean() {
return createBean(new TestBean());
}
Here, we’ve defined how to create a simple new TestBean() using an anonymous class. However, this logic often comes from a third-party library.
One question could be why we wrapped our bean inside a FactoryBean? Why not simply return new TestBean()? The answer to this question is that it’ll give an error that the bean for TestDependency is not found.
After doing the above changes if we run our test case again in section 2.2, it will run successfully.
4. Conclusion
In this article, we’ve gone through the scenarios where we need to disable autowiring of beans. We’ve also seen how to fix these issues with a couple of options we have specifically learned a new way to create a bean using the FactoryBean interface.
All the code examples used in this article are available over on GitHub.