aa7b459803
To make an analogy to read phenomena for transactional databases, this commit effectively fixes the "Phantom Read" problem for Bean Overrides. A phantom read occurs when the BeanOverrideBeanFactoryPostProcessor retrieves a set of bean names by-type twice and a new bean definition for a compatible type has been created in the BeanFactory by a BeanOverrideHandler between the first and second retrieval. Continue reading for the details... Prior to this commit, the injection of test Bean Overrides (for example, when using @MockitoBean) could fail in certain scenarios if overrides were created for nonexistent beans "by type" without an explicit name or qualifier. Specifically, if an override for a SubType was created first, and subsequently an attempt was made to create an override for a SuperType (where SubType extends SuperType), the override for the SuperType would "override the override" for the SubType, effectively removing the override for the SubType. Consequently, injection of the override instance into the SubType field would fail with an error message similar to the following. BeanNotOfRequiredTypeException: Bean named 'Subtype#0' is expected to be of type 'Subtype' but was actually of type 'Supertype$Mock$XHb7Aspo' This commit addresses this issue by tracking all generated bean names (in a generatedBeanNames set) and ensuring that a new bean override instance is created for the current BeanOverrideHandler if a previous BeanOverrideHandler already created a bean override instance that now matches the type required by the current BeanOverrideHandler. In other words, if the generatedBeanNames set already contains the beanName that we just found by-type, we cannot "override the override", because we would lose one of the overrides. Instead, we must create a new override for the current handler. In the example given above, we must end up with overrides for both SuperType and SubType. Closes gh-34025
Spring Framework 
This is the home of the Spring Framework: the foundation for all Spring projects. Collectively the Spring Framework and the family of Spring projects are often referred to simply as "Spring".
Spring provides everything required beyond the Java programming language for creating enterprise applications for a wide range of scenarios and architectures. Please read the Overview section of the reference documentation for a more complete introduction.
Code of Conduct
This project is governed by the Spring Code of Conduct. By participating, you are expected to uphold this code of conduct. Please report unacceptable behavior to spring-code-of-conduct@spring.io.
Access to Binaries
For access to artifacts or a distribution zip, see the Spring Framework Artifacts wiki page.
Documentation
The Spring Framework maintains reference documentation (published and source), GitHub wiki pages, and an API reference. There are also guides and tutorials across Spring projects.
Micro-Benchmarks
See the Micro-Benchmarks wiki page.
Build from Source
See the Build from Source wiki page and the CONTRIBUTING.md file.
Continuous Integration Builds
Information regarding CI builds can be found in the Spring Framework Concourse pipeline documentation.
Stay in Touch
Follow @SpringCentral, @SpringFramework, and its team members on 𝕏. In-depth articles can be found at The Spring Blog, and releases are announced via our releases feed.
License
The Spring Framework is released under version 2.0 of the Apache License.