Spring framework knowledge summary-various exceptions injected into beans

Recently, we encountered a series of exceptions when integrating the spring and hibernate frameworks. This time we mainly explain possible exceptions and solutions in the spring framework.

We use the powerful bean container management mechanism of sping to easily implement the life cycle management of javabean through BeanFactory. However, we will inevitably encounter some exceptions during configuration management:

Exception 1: No qualifying bean of type […] found for dependency

For example, BeanB is automatically injected into BeanA

@Component
public class BeanA {

@Autowired
private BeanB dependency;
…
}

If BeanB is not defined in sping’s Cntextl at this time, then at startup An exception will be thrown: the no such bean definition exception:

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 for the problem is simple expected at least 1 bean which qualifies as autowire candidate for this dependency. There needs to be at least one defined bean for dependency injection. Of course, another possible reason is that we did not set the path for package scanning when using annotations and configuring annotation scanning. Otherwise, there should be no bean defined.

Exception 2: No qualifying bean of type […] is defined

This exception means that there is no qualifying bean of type. The reason is that we have defined two or more identical beans instead of a unique bean. For example, there is a Interface IBeanB, its two implementation classes Bean1 and Bean2

@Component
public class BeanB1 implements IBeanB {
//
}
@Component
public class BeanB2 implements IBeanB {
//
}

If BeanA is injected at this time With the interface IBeanB, Spring does not know which implementation class to use to inject

@Component
public class BeanA {

@Autowired
private IBeanB dependency;
…
}

At this time, the BeanFactory will throw an exception NoSuchBeanDefinitionException

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

from exception expected single matching bean but found 2". It can be seen that the only bean was not found.

Then it can be solved by the following method

@Component
public class BeanA {

@Autowired
@Qualifier("beanB2")
private IBeanB dependency;
…
}

sping will clearly know which Bean is used as the object for injection.

Exception 3: No Bean Named […] is defined

When this exception occurs, go to the Sping context to find the bean by name. , an exception NoSuchBeanDefinitionException may occur

@Component
public class BeanA implements InitializingBean {

@Autowired
private ApplicationContext context;

@Override
public void afterPropertiesSet() {
context.getBean("someBeanName");
}
}

When searching here, there is no definition named someBeanName, causing an exception

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException:
No bean named 'someBeanName' is defined

It is clearly pointed out that it does not exist The bean definition of this name.

Exception 4: Proxied Beans

When a bean uses the JDK dynamic proxy mechanism in the spring context, then the proxy class does not inherit the target object, but it implements the same interface. For this reason, if a Bean is injected with an interface , then there will be no problem, but if an implementation class is injected, the Sping container will not be able to find the bean at this time because the proxy class does not inherit the target class. A very common scenario why a bean is proxied is to use spring's transaction support function. You can use the @Transactional annotation to indicate a transaction, or you can set it in the configuration file.

For example, if ServiceA injects ServiceB, and both services are configured with transactions at the same time, problems will occur through class injection.

@Service
@Transactional
public class ServiceA implements IServiceA{

@Autowired
private ServiceB serviceB;
…
}

@Service
@Transactional
public class ServiceB implements IServiceB{
…
}

Same as this Both Services will run normally if interface injection is used.

@Service
@Transactional
public class ServiceA implements IServiceA{

@Autowired
private IServiceB serviceB;
…
}

@Service
@Transactional
public class ServiceB implements IServiceB{
…
}