A change [1] in Spring Framework 5.3 means that getUrl() on a
RequestEntity will throw an UnsupportedOperationException if the
entity was created using a template.
This commit updates TestRestTemplate to check for instances of
UriTemplateRequestEntity and to resolve the URI using the
entity's UriTemplateHandler instead of calling getUrl() directly.
Fixes gh-25097
[1] a0f4d81db7
This commit reinstanties the isWeBClientPresent() check so that
WebTestClientContextCustomizer is only added if a web client is
available.
See gh-24152
Previously, the web environment configured on `@SpringBootTest` was not
part of the context cache key. As a result, two test classes that has
identical configuration other than one using a MOCK web environment and
the other using a DEFINED_PORT web environment would share a context
when they should not do so. Classes that use MOCK and RANDOM_PORT were
not affected as the use of RANDOM_PORT results in a property for the
port being added to the environment.
This commit adds a new ContextCustomizer, SpringBootTestWebEnvironment,
that is used to capture the `webEnvironment` from `@SpringBootTest`
and use it in its hashCode and equals implementations. This fixes the
problem as all context customizers are evaluated when determing the
equality of two context cache keys.
Fixes gh-23085
Refactor `BootstrapRegistry` support following initial prototype work
with the Spring Cloud team.
This update splits the `BootstrapRegistry` API into `BootstrapRegistry`,
`BootstrapContext` and `ConfigurableBootstrapContext` interfaces and
moves it to the same package as `SpringApplication`.
A new `Bootstrapper` interface has been introduced that can be added
to the `SpringApplication` to customize the `BootstrapRegistry` before
it's used.
Closes gh-23326
Expose the `BootstrapRegisty` to both `ConfigDataLocationResolver` and
`ConfigDataLoader` implementations. The registry is exposed via the
context interfaces and may be used to reuse instances that are expensive
to create. It may also be used to ultimately register beans with the
`ApplicationContext`.
Closes gh-22956
The fix for gh-20916 updated DefinitionsParser so that the
ResolvableType for each MockBean or SpyBean field included the
implementation class from which the field was found. Where the field
was declared with a variable generic signature that was made constant
by its implementation class, this allowed the correct concrete type to
be determined. It also had the unintended side-effect of preventing two
test classes with identical `@MockBean` and `@SpyBean` configuration
from sharing a context as the resolvable types for their mock and spy
bean fields would now be different.
This commit updates DefinitionsParser to only include the
implementation class in the ResolvableType if the field's generic type
is variable. For cases where it is not variable, this restores the
behaviour prior to the fix for gh-20916.
Fixes gh-22566
Deprecate `ConfigFileApplicationListener` and provide a replacement
mechanism that supports arbitrary config data imports.
This commit updates the following areas:
- Extract `EnvironmentPostProcessor` invocation logic from the
`ConfigFileApplicationListener` to new dedicated listener. Also
providing support for `Log` injection.
- Extract `RandomPropertySource` adding logic from the
`ConfigFileApplicationListener` to a dedicated class.
- Migrate to the recently introduced `DefaultPropertiesPropertySource`
class when moving the defaultProperties `PropertySource`
- Replace processing logic with a phased approach to ensure that
profile enablement happens in a distinct phase and that profiles
can no longer be activated on an ad-hoc basis.
- Provide a more predictable and logical import order for processing
`application.properties` and `application.yml` files.
- Add support for a `spring.config.import` property which can be used
to import additional config data. Also provide a pluggable API
allowing third-parties to resolve and load locations themselves.
- Add `spring.config.activate.on-profile` support which replaces the
existing `spring.profiles` property.
- Add `spring.config.activate.on-cloud-platform` support which allows
a config data document to be active only on a given cloud platform.
- Support a `spring.config.use-legacy-processing` property allowing the
previous processing logic to be used.
Closes gh-22497
Co-authored-by: Madhura Bhave <mbhave@vmware.com>
