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

BeanNotOfRequiredTypeException (NullBean instead of null) when calling ApplicationContext.getBean(name, type) [SPR-16342] #20889

Closed
spring-projects-issues opened this issue Jan 3, 2018 · 3 comments
Assignees
Labels
in: core status: declined

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jan 3, 2018

Stefan Mueller opened SPR-16342 and commented

#20582 and #20711 fixed a similar bug. The problem still exists if calling ctx.getBean(name, type) for a null-bean which in older Spring versions (pre 5) returned null and now throws a org.springframework.beans.factory.BeanNotOfRequiredTypeException.

Can be reproduced by adding the following to spring-framework-issues

assertNotNull(ctx.getBean("bean1", IDummy.class)); // Works
assertNull(ctx.getBean("bean4", IDummy.class)); // Throws a BeanNotOfRequiredTypeException

Affects: 5.0.2

Issue Links:

  • #20582 CastClass exception when wiring Map of beans (NullBean instead of 'null' in the map)
  • #20711 CastClass exception (NullBean instead of 'null' value) when getting map of beans directly from ApplicationContext
  • #20099 Introduce null-safety of Spring Framework API
  • #20384 Autowire contract is not honored in cases where FactoryBean or @Bean return null
  • #20890 DefaultLifecycleProcessor throws BeanNotOfRequiredType for null beans (cause of NullBean instance cannot be converted)
@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 3, 2018

Juergen Hoeller commented

I'm afraid this is by design as of Spring Framework 5: getBean never returns null now (in order to allow Java and in particular Kotlin callers to rely on a non-null result), and the NullBean instance indeed cannot be coerced to the specified type there. Note that dependency resolution at injection points may still result in null, just not getBean calls.

For a testing scenario like yours, you could simply call the plain getBean variant without an expected type and check its result for .equals(null) (matching against the NullBean instance at runtime).

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 3, 2018

Juergen Hoeller commented

For some context here...

Cleaner nullability at the API level is a general Spring Framework 5 theme. We're aware that this may cause some regressions against specific API expectations: However, we need this clearer distinction of an uninitialized value (null) versus a fully initialized bean where a factory method happened to return null (where we're exposing a managed NullBean instance for this rather rare case now).

Injection points (in particular annotation-based ones) need to resolve the same way as before, so we consider those previous issues (#20582, #20711) as bugs. I'm afraid getBean fall into a different category here where for all modern purposes (programmatic bootstrapping, programmatic wiring, not least of it all Kotlin) we strongly need the non-null semantics.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 3, 2018

Stefan Mueller commented

Thx for the fast response! The problem is not comming from my own code but from the Spring DefaultLifecycleProcessor getLifecycleBeans method which calls the ctx.getBean(name, type) method and in the case of null-beans throws the BeanNotOfRequiredTypeException.

I opened another issue for this #20890

thx and kind regards
stefan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: declined
Projects
None yet
Development

No branches or pull requests

2 participants