Update `SpringBootContextLoader` so that when possible the
`SpringApplication` remains in control of creating the `Environment`
instance.
Prior to this commit, we would always create the `Environment` in the
`SpringBootContextLoader` and then call `setEnvironment` on the
`SpringApplication`. This meant that the `ApplicationEnvironment`
classes were not used and that `isCustomEnvironment` was set to `true`
so no conversion was applied.
With the updated code, an `ApplicationListener` is used to mutate the
`Environment` instance and add the required test property sources.
Fixes gh-29169
Refine the logic introduced in 64270eca to use a side-effect free
Environment implementation rather than converting the Environment early.
Early conversion can cause condition evaluation issues if
`src/test/resources/application.properties` files are bound to the
`SpringApplication`. Specifically the `spring.main.web-application-type`
property can change the `Environment` type which must happen before
conditions are evaluated.
Fixes gh-29169
Prior to this commit, the `GraphQlTesterContextCustomizer` would
register a `WebGraphQlTester` instance as a `GraphQlTester` bean., only
exposing the `GraphQlTester` type. This is not in line with the
documentation and also does not register the bean definition with the
most specific type.
With this issue, a `@SpringBootTest` integration test will not be
injected with a `WebGraphQlTester` if it asks one.
This commit ensures that the `WebGraphQlTester` is registered as such
and that all related classes are renamed as a result.
Fixes gh-29250
This commit adds the required infrastructure to auto-configure a
`GraphQlTester` or `WebGraphQlTester` in Spring Boot tests.
Specific annotations like `AutoConfigureGraphQlTester` and
`AutoConfigureWebGraphQlTester` will contribute pre-configured beans for
testing a GraphQL with the tester.
This also ships a `ContextCustomize` for contributing a `GraphQlTester`
in the case of a full `@SpringBootTest` integration test against a live
server.
See gh-29140
Update `SpringBootContextLoader` so that the active profiles
property source has a unique name. Prior to this commit, the
default name 'test' was used which could cause ordering issues
if other `@PropertySource` values were added to it later.
Closes gh-28804
Update `SpringBootContextLoader` so that the active profiles
property source has a unique name. Prior to this commit, the
default name 'test' was used which could cause ordering issues
if other `@PropertySource` values were added to it later.
Fixes gh-28776
This commit aligns `SpringBootTest`s to also use `ApplicationEnvironment`
instead of `StandardEnvironment`. This prevents the side-effect of active
profiles from `@ActiveProfiles` from being added to the environment when
doGetActiveProfiles is called. In this case, calling `addActiveProfiles()`
in the environment post processor would result in `@ActiveProfiles` being
added to the environment first, resulting in the wrong order.
The additional call to `setActiveProfiles()` is also not necessary when using
ApplicationEnvironment because that call was put in place to prevent the side-effect
which `ApplicationEnvironment` does not have.
Fixes gh-28530
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>
Stephane Nicoll
Phillip Webb
izeye
Brian Clozel
Andy Wilkinson
Madhura Bhave
Loïc Ledoyen
dreis2211
Leo Li
weixsun
Carlos Rafael de Oliveira Carneiro
Madhura Bhave
Tobias Gesellchen
Andy Wilkinson
Stephane Nicoll