You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on #32933, I noticed some potential issues regarding singleton and scope semantics in our Bean Override support in spring-test, and I verified those assumptions in commit 9c74690.
If a FactoryBean signals it does not manage a singleton, the Bean Override support silently replaces it with a singleton.
An attempt to override a prototype-scoped bean or a bean configured with a custom scope results in one of the following.
If the bean type of the original bean definition is a concrete class, an attempt will be made to invoke the default constructor which will either succeed with undesirable results or fail with an exception if the bean type does not have a default constructor.
If the bean type of the original bean definition is an interface or a FactoryBean that claims to create a bean of a certain interface type, an attempt will be made to instantiate the interface which will always fail with a BeanCreationException.
In light of the above, we should rework the logic in BeanOverrideBeanFactoryPostProcessor.registerReplaceDefinition() so that only singleton beans can be overridden.
The text was updated successfully, but these errors were encountered:
…mework
In gh-33602, we introduced strict singleton enforcement for bean
overrides -- for example, for @MockitoBean, @TestBean, etc. However,
the use of BeanFactory#isSingleton(beanName) can result in a
BeanCreationException for certain beans, such as a Spring Data JPA
FactoryBean for a JpaRepository.
In light of that, this commit relaxes the singleton enforcement in
BeanOverrideBeanFactoryPostProcessor by only checking the result of
BeanDefinition#isSingleton() for existing bean definitions.
This commit also updates the Javadoc and reference documentation to
reflect the status quo.
See gh-33602Closesgh-33800
While working on #32933, I noticed some potential issues regarding singleton and scope semantics in our Bean Override support in
spring-test
, and I verified those assumptions in commit 9c74690.If a
FactoryBean
signals it does not manage a singleton, the Bean Override support silently replaces it with a singleton.An attempt to override a prototype-scoped bean or a bean configured with a custom scope results in one of the following.
FactoryBean
that claims to create a bean of a certain interface type, an attempt will be made to instantiate the interface which will always fail with aBeanCreationException
.In light of the above, we should rework the logic in
BeanOverrideBeanFactoryPostProcessor.registerReplaceDefinition()
so that only singleton beans can be overridden.The text was updated successfully, but these errors were encountered: