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

[spring-projects-issues]

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:

• 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)
• CastClass exception (NullBean instead of 'null' value) when getting map of beans directly from ApplicationContext [SPR-16163] #20711 CastClass exception (NullBean instead of 'null' value) when getting map of beans directly from ApplicationContext
• Introduce null-safety of Spring Framework API [SPR-15540] #20099 Introduce null-safety of Spring Framework API
• 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
• DefaultLifecycleProcessor throws BeanNotOfRequiredType for null beans (cause of NullBean instance cannot be converted) [SPR-16343] #20890 DefaultLifecycleProcessor throws BeanNotOfRequiredType for null beans (cause of NullBean instance cannot be converted)

[spring-projects-issues]

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]

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]

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