This commit switches to 1.0.0-SNAPSHOT for Spring GraphQL, before its
upcoming 1.0.0-M6 version.
This commit adapts to the changes introduced in
spring-projects/spring-graphql#317 : now that `GraphQlClient` has been
introduced, `GraphQlTester` has been aligned with the new
infrastructure. The `@GraphQlTest` and `@SpringBootTest` testing support
is now using different variants for each.
All samples have been updated to use the proper GraphQL terminology, see
and spring-projects/spring-graphql#310 .
See gh-29637
Due to gh-29695, smoketest.profile.ActiveProfilesTests starts a web
server bound to the default port (8080) despite the test setting
`webEnvironment` to `NONE`.
This commit works around the problem by running the tests with
server.port set to zero.
Closes gh-30086
ContextHandler.ApproveAliases has been deprecated. We tried to
replace it with AllowedResourceAliasChecker but it does not
behave in the same way and causes CI failures on Windows.
ContextHandler.ApproveAliases always returns true so we should
hardcode our own implementation that does the same.
Closes gh-30045
H2 2.x contains several important changes such as moving the primary key
generation mechanism to a sequence-based identifier. This commit fixes
a number of tests that were failing.
Closes gh-29651
Co-authored-by: Andy Wilkinson <wilkinsona@vmware.com>
Previously, the error page security filter passed the request's URI
to the privilege evaluator. This was incorrect in applications with
a custom context path as the privilege evaluator must be passed a
path that does not include the context path and the request URI
includes the context path.
This commit updates the filter to use UrlPathHelper's
pathWithinApplication instead. The path within the application does
not include the context path. In addition, pathWithinAppliation
also correctly handles applications configured with a servlet
mapping other than the default of /.
Closes gh-29299
Co-Authored-By: Andy Wilkinson <wilkinsona@vmware.com>
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 `ErrorPageSecurityFilter` verified if
access to the error page was allowed by invoking the
`WebInvocationPrivilegeEvaluator` with the Authentication from the
`SecurityContextHolder`.
This meant that access to the error page was denied for a `null` Authentication
or `AnonymousAuthenticationToken` in cases where the error page required
authenticated access. This prevented authorized users from accessing the
error page in case the Authentication wasn't retrievable for the error dispatch,
which is the case for `@Transient` authentication or stateless session policy.
This commit updates the `ErrorPageSecurityFilter` to check access to the error page
only if the error is an authn or authz error in cases where an authentication object
is not found in the SecurityContextHolder. This makes the error response consistent
when bad credentials or no credentials are used while also allowing access to previously
authorized users.
Fixes gh-28953
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
There are dedicated smoke tests for Hazelcast, MongoDB and Redis
that run on CI.
This commit also polishes some of the other smoke tests related to
Spring Session
Change the order of `DataSourceScriptDatabaseInitializerDetector` so
that it always runs last. This update allows script initialization to
be combined with a high-level migration tool such as Flyway.
Closes gh-26692
This commit reworks the initial proposal so that jobs and triggers are
treated as first class concepts.
`/actuator/quartz` now returns the group names for jobs and triggers.
`actuator/quartz/jobs` returns the job names, keyed by the available
group names, while `/actuator/quartz/triggers` does the same for
triggers.
`/actuator/jobs/{groupName}` provides an overview of a job group. It
provides a map of job names with the class name of the job.
implementation
`/actuator/triggers/{groupName}` provides an overview of a trigger
group. There are five supported trigger implementations: cron, simple,
daily time interval, calendar interval, and custom for any other
implementation. Given that each implementation has specific settings,
triggers are split in five objects.
`/actuator/jobs/{groupName}/{jobName}` provides the full details of a
particular job. This includes a sanitized data map and a list of
triggers ordered by next fire time.
`/actuator/triggers/{groupName}/{triggerName}` provides the full details
of a particular trigger. This includes the state, its type, and a
dedicate object containing implementation-specific settings.
See gh-10364
Deprecate the `Bootstrapper` interface entirely and provide a
`BootstrapRegistryInitializer` alternative so that people can migrate.
Unfortunately our previous attempt to fix the typo in the `Bootstrapper`
interface didn't provide us a way to remove the deprecated method
without impacting users. It was also problematic for people who were
implementing `Bootstrapper` rather than using a lambda since they needed
to introduce the deprecated method.
We unfortunately can't see a way to fix the original typo without
introducing a new interface.
Fixes gh-25735
userDefinedMappingsSecureByDefault in
SampleSessionWebFluxApplicationTests may fail with an NPE if the
session times out before the initial response is sent due to the absence
of a SESSION cookie in the response. The test uses a short session
timeout (2 seconds) and we've seen the problem occur on CI when,
presumably, a noisy neighbour has caused some CPU starvation.
This commit increases the timeout to 5 seconds to reduce the chance of
a short period of CPU starvation causing the test to fail.
Closes gh-25572
Previously, actuator endpoints were registered with Jersey upon
injection of the ResourceConfig bean into a registrar class rather than
using a ResourceConfigCustomizer. This was done to fix a problem
when running the Actuator on a separate port where the main application
context's customizers were also applied to the management context,
breaking the singleton contract for those resources. This approach
meant that the registration could be performed at any point after the
ResourceConfig had been created. When Jersey's configured as a Filter
this resulted in the registration failing as the attempt was being made
after the Filter lifecyle callbacks which make the ResourceConfig
immutable.
This commit reworks the endpoint registration to be performed using a
ManagementContextResourceConfigCustomizer, a resource config customizer
that's only applied to the ResourceConfig that's used by the Actuator.
When there's a separate management context, this ResourceConfig is
created by the Actuator's auto-configuration and the management context
resource config customizers are applied to it during its creation. The
main application's customizers are not applied. When the actuator is
using the same context as the main application, this ResourceConfig is
created by the main application. In this case a
ResourceConfigCustomizer is defined that delegates to all
ManagementContextResourceConfigCustomizers, allowing them to register
the actuator endpoints with the main ResourceConfig.
Fixes gh-25262
Previously, DataSource initialization was triggered via a
BeanPostProcessor or a schema created event from JPA. This caused
numerous problems with circular dependencies, bean lifecycle, etc and
added significant complexity.
This commit reworks DataSource initialization to remove the use of a
BeanPostProcessor entirely. In its place, DataSource initialization is
now driven by an InitializingBean with dependency relationships
between beans ensuring that initialization has been performed before
the DataSource is used. This aligns with the approach that's worked
well with Flyway and Liquibase.
More changes are planned to further simplify DataSource initialization.
The changes in this commit are a foundation for those changes. Any new
public API in this commit is highly likely to change before the next
GA.
Fixes gh-13042
Fixes gh-23736
Update `build.gradle` files to ensure that `junit-platform-launcher` is
a `testRuntimeOnly` dependency. This ensures that tests can be run from
Eclipse.
Closes gh-25074
Exclude `@ConfigurationProperties` beans from method validation so
that `@Validated` can be used on final classes without the method
validation post-processor throwing an exception.
This commit introduces a `FilteredMethodValidationPostProcessor` class
which will use `MethodValidationExcludeFilters` to exclude beans from
method validation processing. Using `@EnableConfigurationProperties`
will automatically register an appropriate filter.
Closes gh-21454
Replace `WebSecurityConfigurer` and `WebSecurityConfigurerAdapter`
configurations with `WebSecurityCustomizer` or `SecurityFilterChain`
beans.
Closes gh-23421
Previously, the base path of a servlet-based management server could be
configured using management.server.servlet.context-path but there was no
equivalent property for WebFlux.
This commit introduces a new property, management.server.base-path,
that can be used with both servlet and reactive management servers. The
existing servlet-specific property has been deprecated in favour of the
new general property. When using the servlet stack, if both the general
property and the servlet-specific property are set, the new general
property takes precedence. When using the reactive stack, only the new
general property is considered.
Closes gh-22906
Refactor `ConfigData` processing code to make it less awkward to
follow.
Prior to this commit the `ConfigDataLocationResolver` would take a
String location and return a `ConfigDataLocation` instance. This was
a little confusing since sometimes we would refer to `location` as the
String value, and sometimes it would be the typed instance. We also
had nowhere sensible to put the `optional:` prefix logic and we needed
to pass a `boolean` parameter to a number of methods. The recently
introduced `Orgin` support also didn't have a good home.
To solve this, `ConfigDataLocation` has been renamed to
`ConfigDataResource`. This frees up `ConfigDataLocation` to be used
as a richer `location` type that holds the String value, the `Orgin`
and provides a home for the `optional:` logic.
This commit also cleans up a few other areas of the code, including
renaming `ResourceConfigData...` to `StandardConfigData...`. It also
introduces a new exception hierarchy for `ConfigDataNotFoundExceptions`.
Closes gh-23711
Constructor calls like new AtomicInteger(0) cause a volatile write that
can be saved in cases where the constructor parameter is the default
value.
See gh-23575
Previously, the default servlet was registered automatically when using
embedded Jetty, Tomcat, or Undertow. However, it is not used by the
majority of applications where Spring MVC's DispatcherServlet will be
the only servlet that's needed. As such configuring the default servlet
was wasting CPU and memory.
This commit changes the default for registering the default servlet to
false. It can be re-enabled by setting
server.servlet.register-default-servlet=true.
Closes gh-22915
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
Previously, the project version was included in the name of the
Ant-built jar and the integration test assumed that there would be a
single jar in the output directory. This assumption did not hold true
if the project's version had changed and the project had been built
again without a clean. This resulted in two jars, one for the previous
version and one for the current version, in the output directory. This
caused a test failure.
This commit updates the build.xml to remove the version from the name
of the Ant-built jar and updates the integration test to find it.
Closes gh-22782
This commit adapts the auto-configuration for the new core r2dbc support
in Spring Framework and provides auto-configuration for
R2dbcEntityOperations.
Closes gh-22708
This commit also switches to RSocket SNAPSHOTs and updates the
repository configuration to rely on "libs-snapshot", since the RSocket
SNAPSHOTs are mirrored there.
See gh-22640
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>
Previously, Spring Boot's modules published Gradle Module Metadata
(GMM) the declared a platform dependency on spring-boot-dependencies.
This provided versions for each module's own dependencies but also had
they unwanted side-effect of pulling in spring-boot-dependencies
constraints which would influence the version of other dependencies
declared in the same configuration. This was undesirable as users
should be able to opt in to this level of dependency management, either
by using the dependency management plugin or by using Gradle's built-in
support via a platform dependency on spring-boot-dependencies.
This commit reworks how Spring Boot's build uses
spring-boot-dependencies and spring-boot-parent to provide its own
dependency management. Configurations that aren't seen by consumers are
configured to extend a dependencyManagement configuration that has an
enforced platform dependency on spring-boot-parent. This enforces
spring-boot-parent's version constraints on Spring Boot's build without
making them visible to consumers. To ensure that the versions that
Spring Boot has been built against are visible to consumers, the
Maven publication that produces pom files and GMM for the published
modules is configured to use the resolved versions from the module's
runtime classpath.
Fixes gh-21911