Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-issuemaster opened this issue Oct 12, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Oct 12, 2017

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:

  • #20582 CastClass exception when wiring Map of beans (NullBean instead of 'null' in the map)
  • #20384 Autowire contract is not honored in cases where FactoryBean or @Bean return null

Referenced from: commits 91a8993

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 12, 2017

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 12, 2017

Loabe Me commented

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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 12, 2017

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.