Prior to this commit, ApplicationContext caching support was broken if
two Bean Override fields declared the same annotations but in a
different order.
This commit fixes that by switching to Set semantics for the
annotations declared on a Bean Override field.
Closes gh-33633
Prior to this commit, the SockJs server support would use
`java.util.Random` to send a random value to clients when they request
the `/info` endpoint. Per protocol, clients can use this value as a
source of entropy for generating a random session id.
In practice, this is not used by clients. For example, the SockJS
javascript client is using a cryptographically safe API to generate
session ids.
While this has no concrete effect on known clients, this commit improves
the random source in the server support by switching to
`java.security.SecureRandom`.
Closes gh-33632
Prior to this commit, BeanOverrideBeanFactoryPostProcessor replaced
existing bean definitions with "pseudo" bean definitions; however, that
is unnecessary. An existing BeanDefinition is suitable as-is and does
not need to be replaced with a pseudo/fake definition.
To address that, this commit reregisters an existing bean definition
and only registers a new bean definition when creating a bean
definition for a nonexistent bean.
As a side effect, we no longer need to copy primary and fallback flags.
Closes gh-33627
Prior to this commit, @MockitoBean could be used to either create or
replace a bean definition, but @TestBean could only be used to replace
a bean definition.
However, Bean Override implementations should require the presence of
an existing bean definition by default (i.e. literally "override" by
default), while giving the user the option to have a new bean
definition created if desired.
To address that, this commit introduces a new `enforceOverride`
attribute in @TestBean and @MockitoBean that defaults to true but
allows the user to decide if it's OK to create a bean for a nonexistent
bean definition.
Closes gh-33613
In a Cacheable reactive method, if an exception is propagated from
both the method and the caching infrastructure, an NPE could previously
surface due to the `CacheAspectSupport` attempting to perform an
`onErrorResume` with a `null`. This change ensures that in such a case
the user-level exception from the method is propagated instead.
Closes gh-33492
Prior to this commit, a non-singleton FactoryBean was silently replaced
by a singleton bean. In addition, bean definitions for prototype-scoped
and custom-scoped beans were replaced by singleton bean definitions
that were incapable of creating the desired bean instance. For example,
if the bean type of the original bean definition was a concrete class,
an attempt was made to invoke the default constructor which either
succeeded with undesirable results or failed with an exception if the
bean type did not have a default constructor. If the bean type of the
original bean definition was an interface or a FactoryBean that claimed
to create a bean of a certain interface type, an attempt was made to
instantiate the interface which always failed with a
BeanCreationException.
To address the aforementioned issues, this commit reworks the logic in
BeanOverrideBeanFactoryPostProcessor so that an exception is thrown
whenever an attempt is made to override a non-singleton bean.
Closes gh-33602
New NoTransactionInContextException instances are created frequently in
TransactionContextManager#currentContext() when there is no transaction,
we could reuse the same instance instead to reduce the GC pressure.
Closes gh-33601
The tests introduced in this commit reveal the following issues in our
Bean Override support.
- 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 order to allow third parties (for example, Spring Boot) to ensure
that a DynamicPropertyRegistrarBeanInitializer has been registered in
an ApplicationContext which has not been customized by the
DynamicPropertiesContextCustomizer, this commit converts
DynamicPropertyRegistrarBeanInitializer to a public API for use in such
special use cases.
Closes gh-33593
