Regression: SPR-12443 breaks singleton bean references within a configuration class with null arguments [SPR-13887]

[spring-projects-issues]

László Váradi opened SPR-13887 and commented

We are using @Configuration classes over a hundred of modules now, and just tried to upgrade from 4.1.1 to 4.1.9. However we have faced that the internal method calls now passes the arguments.

Singleton bean methods have arguments also, its dependencies. Until now, we have called these methods internally with null arguments, but it won't work now, because in this way BeanFactory will skip to lookup arguments, but will use the provided null argument, if the bean is not already created.

#17048 is about prototype beans, but it is applied to all beans, and removed a check from AbstractBeanFactory mentioned in #17094.

BeanMehtodInterceptor should really pass arguments only in case of prototype bean, or AbstractBeanFactory should avoid passed arguments in case of singleton beans, but as it is now, it is not consistent. Bean creation depends on bean creation order (created as it own, or as a depenency)

---

Affects: 4.1.9

Issue Links:

• SPR-12443 breaks Spring Security's AuthenticationConfiguration [SPR-12488] #17094 SPR-12443 breaks Spring Security's AuthenticationConfiguration
• BeanMethodInterceptor doesn't forward user-provided arguments to getBean(name, args) [SPR-12443] #17048 BeanMethodInterceptor doesn't forward user-provided arguments to getBean(name, args)
• ObjectFactory lacks method for getting bean with specified constructor arguments [SPR-13956] #18529 ObjectFactory lacks method for getting bean with specified constructor arguments

Referenced from: commits 5ed9046, d2b9dbf

[spring-projects-issues]

Juergen Hoeller commented

We're going to revisit this for 4.2.5... might be a bit tricky to not break anybody else's arrangements there; I'll see what we can do.

In any case, please note that there are not going to be further 4.1.x releases. If you're upgrading from an older release, please upgrade to 4.2.5 right away. After all, 4.3 is coming in just a couple of months, so even 4.2.x is in maintenance mode already.

Juergen

[spring-projects-issues]

László Váradi commented

Hi,

Thanks for the quick response. We will wait for 4.2.5.

• LV

[spring-projects-issues]

Juergen Hoeller commented

This is a bit of a tricky issue since part of 4.1's mission (only really completed in 4.1.3 which was the basis for Spring Boot 1.2 GA) was to consistently handle bean arguments across getBean calls, @Lookup methods and @Bean methods. We didn't want to artifically exclude singleton beans there, since there are scenarios where startup order can be carefully controlled, in particular with programmatic initialization-driving access to lazy singletons.

Also, it is an unusual combination to have @Bean method cross-references next to factory method arguments there. I would rather expect a reference to another bean (even in the same configuration class) through a factory method argument as well then: that is, not call the other bean's factory method but rather declare an argument of its type on your own factory method. That's a more consistent style and avoids the artificial stubbing of method arguments as nulls.

All of that said, it is easy enough to cover this case: Regular @Bean method arguments can never be null since they are implicitly required when autowired through the container. For methods designed for prototypes or custom scopes, there may be exceptions to this rule, but for singleton beans it is a safe assumption. As a consequence, when BeanMethodInterceptor encounters a null argument now, it won't forward the args to the factory in case of a singleton target bean, assuming that they are just intended as stubs.

Rolled into master now, and to be backported for the 4.2.5 release next week.