Recently, I ran into a small issue and found the following article to be very helpful.
Suppose, you have a Spring
@Service class (MileageFeeCalculator) that has an @Autowired field (rateService), but the field is null when I try to use it. The logs show that both the MileageFeeCalculator bean and the MileageRateService bean are being created, but I get a NullPointerException whenever I try to call the mileageCharge method on my service bean. Why isn't Spring autowiring the field?Controller class:
@Controller
publicclassMileageFeeController{
@RequestMapping("/mileage/{miles}")
@ResponseBody
publicfloat mileageFee(@PathVariableint miles){
MileageFeeCalculator calc =newMileageFeeCalculator();
return calc.mileageCharge(miles);
}
}Service class:
@Service
publicclassMileageFeeCalculator{
@Autowired
privateMileageRateService rateService;// <--- autowired="" be="" is="" null="" should="" span="">
publicfloat mileageCharge(finalint miles){
return(miles * rateService.ratePerMile());// <--- npe="" span="" throws="">
}
}--->--->Service bean that should be autowired in
MileageFeeCalculator but it isn't:@Service
publicclassMileageRateService{
publicfloat ratePerMile(){
return0.565f;
}
}The field annotated
@Autowired is null because Spring doesn't know about the copy of MileageFeeCalculator that you created with new and didn't know to autowire it.The Spring Inversion of Control (IoC) container has three main logical components: a registry (called the
ApplicationContext) of components (beans) that are available to be used by the application, a configurer system that injects objects' dependencies into them by matching up the dependencies with beans in the context, and a dependency solver that can look at a configuration of many different beans and determine how to instantiate and configure them in the necessary order.The IoC container isn't magic, and it has no way of knowing about Java objects unless you somehow inform it of them. When you call
new, the JVM instantiates a copy of the new object and hands it straight to you--it never goes through the configuration process. There are three ways that you can get your beans configured.Inject your beans
The most preferable option is to let Spring autowire all of your beans; this requires the least amount of code and is the most maintainable. To make the autowiring work like you wanted, also autowire the
MileageFeeCalculator like this:@Controller
publicclassMileageFeeController{
@Autowired
privateMileageFeeCalculator calc;
@RequestMapping("/mileage/{miles}")
@ResponseBody
publicfloat mileageFee(@PathVariableint miles){
return calc.mileageCharge(miles);
}
}If you need to create a new instance of your service object for different requests, you can still use injection by using the Spring bean scopes.
Tag that works by injecting the
@MileageFeeCalculator service object: working-inject-beanUse @Configurable
If you really need objects created with
new to be autowired, you can use the Spring @Configurable annotation along with AspectJ compile-time weaving to inject your objects. This approach inserts code into your object's constructor that alerts Spring that it's being created so that Spring can configure the new instance. This requires a bit of configuration in your build (such as compiling with ajc) and turning on Spring's runtime configuration handlers (@EnableSpringConfigured with the JavaConfig syntax). This approach is used by the Roo Active Record system to allow new instances of your entities to get the necessary persistence information injected.@Service
@Configurable
publicclassMileageFeeCalculator{
@Autowired
privateMileageRateService rateService;
publicfloat mileageCharge(finalint miles){
return(miles * rateService.ratePerMile());
}
}Tag that works by using
@Configurable on the service object: working-configurableManual bean lookup: not recommended
This approach is suitable only for interfacing with legacy code in special situations. It is nearly always preferable to create a singleton adapter class that Spring can autowire and the legacy code can call, but it is possible to directly ask the Spring application context for a bean.
To do this, you need a class to which Spring can give a reference to the
ApplicationContext object:@Component
publicclassApplicationContextHolderimplementsApplicationContextAware{
privatestaticApplicationContext context;
@Override
publicvoid setApplicationContext(ApplicationContext applicationContext)throwsBeansException{
context = applicationContext;
}
publicstaticApplicationContext getContext(){
return context;
}
}Then your legacy code can call
getContext() and retrieve the beans it needs:@Controller
publicclassMileageFeeController{
@RequestMapping("/mileage/{miles}")
@ResponseBody
publicfloat mileageFee(@PathVariableint miles){
MileageFeeCalculator calc =ApplicationContextHolder.getContext().getBean(MileageFeeCalculator.class);
return calc.mileageCharge(miles);
}
}
The original thread appeared on StackOverflow: https://stackoverflow.com/questions/19896870/why-is-my-spring-autowired-field-null