Prior to this commit, resource management around
`ClientHttpRequestFactory` and `RestTemplate` was unclear. Some
factories implementation were implementing a `DisposableBean` and other
contracts were not managing request factory resources.
In the meantime, neither `ClientHttpRequestFactory` nor `RestTemplate`
are typically meant to be contributed as beans to the application
context. Most often, they're instantiated within beans and their
lifecycle should be managed by those.
This commit makes all `ClientHttpRequestFactory` `Closeable` and ensures
that all existing implementations have a similar behavior between
`dispose()` and `close()`. Since `RestTemplate` (actually
`HttpAccessor`) can instantiate factories on its own, they also now
extend `Closeable` to properly close those resources, if not externally
managed.
Closes gh-29010
This commit fixes an issue in StringDecoder, where, if the buffer did
not contain any delimiters, it was released before it was relayed to
any subscribers.
Closes gh-29119
This commit adds predicates variants that accept `String className`
instead of actual `Class<?>` when checking for fields and method hints.
This is useful when the type under test is not visible from the current
test class.
Closes gh-29143
The ability to set a system property to change the default
CacheAwareContextLoaderDelegate was only needed by the Spring Native
project in the Spring Framework 5.3.x line and should not be used by
other projects.
This commit therefore reverts the changes made in conjunction with
gh-27540.
Closes gh-29061
This commit refines the implementation to be more
lenient when defaultPersistenceUnitRootLocation is equals
to ORIGINAL_DEFAULT_PERSISTENCE_UNIT_ROOT_LOCATION and an
IOException is thrown, which happens when running on
native image.
Closes gh-29137
Previously, if `@Order` is specified on a `@Bean` method, and the
candidate bean is defined in a parent context, its order wasn't taken
into account when retrieving the bean from a child context.
This commit makes sure the metadata of a bean is taken into
consideration in all cases.
Closes gh-29105
For certain use cases it is beneficial to be able to compute something
during AOT build-time processing and then retrieve the result of that
computation during AOT run-time execution, without having to deal with
code generation on your own.
To support such use cases, this commit introduces an AotTestAttributes
mechanism in the Spring TestContext Framework with the following
feature set.
- conceptually similar to org.springframework.core.AttributeAccessor in
the sense that attributes are generic metadata
- allows an AOT-aware test component to contribute a key-value pair
during the AOT build-time processing phase, where the key is a String
and the value is a String
- provides convenience methods for storing and retrieving attributes as
boolean values
- generates the necessary source code during the AOT build-time
processing phase in the TestContext framework to create a persistent
map of the attributes
- provides a mechanism for accessing the stored attributes during AOT
run-time execution
Closes gh-29100
