Spring Java configuration using Autowired called NPE

Question

I find it hard to understand why something in Spring's Java configuration using @Autowired does not work.

First, I'm trying to move all my @Autowired annotations to Java Config classes. This causes my "POJOs" to return to real POJOs. Then, I can not only easily test them outside the context of Spring, but also easily and easily use mock objects.

So I first tried this:

 @Configuration public class Module3ConfigClass { @Autowired private Module1Bean1 module1Bean1; @Autowired private Module2Bean1 module2Bean1; @Bean public Module3Bean1 module3Bean1() { return new Module3Bean1(module1Bean1, module2Bean1); } } 

However, when the Module3Bean1 constructor is Module3Bean1 , both passed to Beans are zero. If you do not follow the naming convention above, both of these Beans will be created in a separate Java configuration file. Also note that everything is connected correctly - I know this, because everything works fine when the @Autowired tags are in the corresponding fields of the private member inside Module3Bean1 .

FWIW, I tried adding the @DependsOn annotation to the module3Bean1() method, but had the same results. I think I just wanted to understand this behavior, is it correct (I suspect this is so, but why)?

Finally, I found an acceptable workaround shown here:

 @Configuration public class Module3ConfigClass { @Bean @Autowired public Module3Bean1 module3Bean1(Module1Bean1 module1Bean1, Module2Bean1 module2Bean1) { return new Module3Bean1(module1Bean1, module2Bean1); } } 

It seems wonderful to me, but if someone wants to comment on it, that would be welcome too.

Answer 1

I think you are facing the same problem as me. In my case, the problem was an invalid xml configuration. In my module B, I had a configuration like:

 <beans> <context:component-scan base-package="com.moduleB"/> <import resource="classpath:applicationContext-moduleA.xml"/> </beans> 

In the context of moduleA, I posted the annotation "context: annotation-config". When I change the import / context order:

 <beans> <import resource="classpath:applicationContext-moduleA.xml"/> <context:component-scan base-package="com.moduleB"/> </beans> 

The use of Autowiring for configuration class properties has begun.

Answer 2

We had the same problem, and came to the conclusion that the error arose because we had a circular dependency in which a BeanPostProcessor participated.

• The PropertyPlaceholderConfigurer (BeanPostProcessor) property is configured to set the propertiesArray property using another bean:

   <bean id="globalPropertyPlaceholderConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" lazy-init="false" depends-on="javaLoggingConfigurer"> <property name="locations"> <list> <value>classpath:config/host/${env.instance}.properties</value> <value>WEB-INF/config/host/${env.instance}.properties</value> </list> </property> <property name="ignoreResourceNotFound" value="true" /> <property name="propertiesArray" value="#{springPropertyFinder.findProperties()}" /> </bean> 

• The springPropertyFinder bean used to set the Array properties is not a BeanPostProcessor, but a "normal" bean that collects all instances of Properties using:

   public Properties[] findProperties() { Map<String, Properties> propertiesMap = applicationContext.getBeansOfType(Properties.class); for (String title : propertiesMap.keySet()) { PropertiesLoggerUtil.logPropertiesContent(logger, "Springcontext Properties ("+title+")", propertiesMap.get(title)); } return propertiesMap.values().toArray(new Properties[propertiesMap.size()]); } 

• The @Configuration class contained a bean of type Properties

So, our assumption is that the @Configuration class was created without processing using ConfigurationClassPostProcessor (also BeanPostProcessor), since PropertyPlaceholderConfigurer depends on springPropertyFinder, which depends on the bean properties in the @Configuration class. In these circumstances, the order of BeanPostProcessors is probably not configured.

This setup described worked in XML, but not with the Java configuration.