Oleg Zhurakousky opened SPR-15829 and commented

Configuration below reproduces the issue

@Autowired
private FooStrategy foo;

@Bean
public FooStrategy createFoo() {
	return null;
}
	
public String doSomethingWithFoo(){
	return foo.doSomething();;
}

The bottom line is that the above does NOT result in “Field foo in MyApplication required a bean of type 'FooStrategy' that could not be found.” And instead it results in NPE. But the NPE is not happening during AC initialization, rather during the invocation of any callback to 'foo'.

Regardless of the reason to return null from the factory method, the main issue IMHO is that @Autowire contract is not followed for this type of scenario.

Affects: 5.0 RC3

Issue Links:

• BeanNotOfRequiredTypeException (NullBean instead of null) when calling ApplicationContext.getBean(name, type) [SPR-16342] #20889 BeanNotOfRequiredTypeException (NullBean instead of null) when calling ApplicationContext.getBean(name, type)
• CastClass exception when wiring Map of beans (NullBean instead of 'null' in the map) [SPR-16033] #20582 CastClass exception when wiring Map of beans (NullBean instead of 'null' in the map)
• BeanDefinitionValidationException when beans are null (NullBean) and initMethod is set [SPR-16063] #20612 BeanDefinitionValidationException when beans are null (NullBean) and initMethod is set
• null FactoryBean results in BeanCreationException [SPR-16250] #20797 null FactoryBean results in BeanCreationException
• Consistent non-exposure of null beans in the BeanFactory API [SPR-17034] #21572 Consistent non-exposure of null beans in the BeanFactory API
• @Lazy collection of optional elements should not crash when no candidates are found [SPR-15858] #20413 @Lazy collection of optional elements should not crash when no candidates are found

Referenced from: commits 30bd582, b94302b