BeanDefinitionValidationException when beans are null (NullBean) and initMethod is set [SPR-16063]

[spring-projects-issues]

Loabe Me opened SPR-16063 and commented

After upgrading to Spring 5.0.0 the following exception occurs during application runtime:

Caused by: org.springframework.beans.factory.support.BeanDefinitionValidationException: Couldn't find an init method named 'initialize' on bean with name 'offlineMode'
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1795)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1772)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1700)

I tracked it down to the AbstractAutowireCapableBeanFactory.invokeCustomInitMethod where the bean object is correctly typed as NullBean.class. But nonetheless there is a BeanDefinitionValidationException thrown because the initMethod is null. Is this an expected change in behavior from 4.x to 5.x? For our situation its a breaking change because there is a 3rd party library initialized that can produce null beans. If that change was expected, whats the correct way to do handle that situation with 5.x?

---

Affects: 5.0 GA

Issue Links:

• 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)
• Autowire contract is not honored in cases where FactoryBean or @Bean return null [SPR-15829] #20384 Autowire contract is not honored in cases where FactoryBean or @Bean return null

Referenced from: commits 91a8993

[spring-projects-issues]

Juergen Hoeller commented

While it is rather unusual for an init method to be declared against a potential null bean, we simply ignored such a setting before and should still do so now. I'll fix this for 5.0.1, to be available in tonight's 5.0.1.BUILD-SNAPSHOT.

[spring-projects-issues]

Loabe Me commented

Is it the same behavior for the destroyMethod? It was also ignored there before.

[spring-projects-issues]

Juergen Hoeller commented

Indeed, I've addressed it in our requiresDestruction check as well. We've just logged a warning for missing destroy methods anyway, but still, no need to even go there in the null case.

I'm about to commit this already, so feel free to give the next 5.0.1.BUILD-SNAPSHOT a try (to be available in about half an hour).