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
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
Spring Boot's testing support registers a DynamicPropertyRegistry as a
bean in the ApplicationContext, which conflicts with the
DynamicPropertyRegistry registered as a bean by the Spring TestContext
Framework (TCF) since Spring Framework 6.2 M2.
To avoid that conflict and to improve the user experience for Spring's
testing support, this commit introduces a DynamicPropertyRegistrar API
to replace the DynamicPropertyRegistry bean support.
Specifically, the TCF no longer registers a DynamicPropertyRegistry as
a bean in the ApplicationContext.
Instead, users can now register custom implementations of
DynamicPropertyRegistrar as beans in the ApplicationContext, and the
DynamicPropertiesContextCustomizer now registers a
DynamicPropertyRegistrarBeanInitializer which eagerly initializes
DynamicPropertyRegistrar beans and invokes their accept() methods with
an appropriate DynamicPropertyRegistry.
In addition, a singleton DynamicValuesPropertySource is created and
registered with the Environment for use in
DynamicPropertiesContextCustomizer and
DynamicPropertyRegistrarBeanInitializer, which allows
@DynamicPropertySource methods and DynamicPropertyRegistrar beans to
transparently populate the same DynamicValuesPropertySource.
Closes gh-33501
Since we now use asciidoctor-tabs instead of spring-asciidoctor-backends,
we no longer need the `role="primary"` and `role="secondary"` attributes
for tab groups.
Closes gh-33506
This commit revises the reference documentation for Spring JMX
annotations for various reasons including, but not limited to, the
following.
- Type names such as ManagedResource are often ambiguous, especially
when discussing an annotation like @ManagedResource instead of
org.springframework.jmx.export.metadata.ManagedResource which is a
class.
- AnnotationTestBean implements IJmxTestBean, even though an annotated
MBean is not required to implement any interfaces, and in fact the
example is meant to demonstrate that an annotated POJO suffices.
- @ManagedOperationParameter annotations are unnecessarily declared in
the @ManagedOperationParameters container.
- The documentation sometimes refers to JmxTestBean when it should
instead refer to AnnotationTestBean.
- Inconsistent and confusing wording for annotation attributes,
properties, managed attributes, etc.
- The tables refer to "source-level metadata types/parameters" when
they should refer to Spring JMX annotations and their attributes.
- The annotation and attribute tables have inconsistent ordering and
naming for column headers.
- @ManagedNotification and @ManagedMetric are not mentioned.
- The AutodetectCapableMBeanInfoAssembler example is broken since it
uses the non-annotated JmxTestBean instead of the AnnotationTestBean.
As a side note, the JmxTestBean in our test suite still contains
XDoclet "annotations" which can be safely removed. 😉
Closes gh-33466
This commit updates the Evaluation chapter to reflect the following.
- SimpleEvaluationContext no longer has a create() method. Instead it
has forPropertyAccessors(), forReadOnlyDataBinding(), and
forReadWriteDataBinding() factory methods.
- SpEL cannot automatically create missing array elements or grow the
size of an array like it can for a collection.
Closes gh-33456
This commit revises the AOP proxying section as follows.
- Documents all limitations of CGLIB-based proxies
- Documents self injection as alternative to AopContext.currentProxy()
- Avoids use of flippant language
See gh-33454
Closes gh-33455
Prior to this commit, the main() method attempted to retrieve a
TransferService bean from the context, but no such bean had been
configured in the context.
This commit addresses that by configuring a TransferService bean in the
context.
Closes gh-33446
On the client side, supports `name=value` pairs. Placeholders in values
are resolved by the `embeddedValueResolver`.
On the server side, additionally supports `name` and `!name` syntax.
Closes gh-33309
Sam Brannen
Yanming Zhou
Johnny Lim
Sébastien Deleuze
Antoine Rey
Brian Clozel
alfredo-toledano
rstoyanchev
Olga Maciaszek-Sharma
Simon Baslé
Stéphane Nicoll