GraphiQL is useful when working on a GraphQL API - it allows
developers to craft queries and test newly developed feature. This
is not enabled by default, as this should not be exposed in production
without the developer's knowledge.
This commit flips this value when Spring Boot devtools is active for a
better developer experience.
See gh-29140
Add `DevToolsR2dbcAutoConfiguration` to automatically shutdown in-memory
R2DBC databases before restarting. Prior to this commit, restarts that
involved SQL initialization scripts could fail due to dirty database
content.
The `DevToolsR2dbcAutoConfiguration` class is similar in design to
`DevToolsDataSourceAutoConfiguration`, but it applies to both pooled
and non-pooled connection factories. The `DataSource` variant does not
need to deal with non-pooled connections due to the fact that
`EmbeddedDataSourceConfiguration` calls `EmbeddedDatabase.shutdown`
as a `destroyMethod`. With R2DB we don't have an `EmbeddedDatabase`
equivalent so we can always trigger a shutdown for devtools.
Fixes gh-28345
Polish commit 5ca687c9a6 had an accidental side-effect of changing
the 'Sec-WebSocket-Key' header value to lowercase. This breaks
connections since the value needs to be echoed unchanged in the
"Sec-WebSocket-Accept" header.
Fixes gh-27147
Previously, several tests in FileSystemWatcherTests assumed that all
of the changes detected by the watcher would be grouped into a single
change set. This assumption breaks down when a test runs slowly (due
to CPU or IO contention, for example), and making changes to the file
system takes long then the watcher's polling interval. When this
happens, the changes will be split across two (or more).
This commit attempts to make the tests more robust. The tests now
tolerate multiple changes sets by combining them and asserting that
across the n change sets, only the expected changes were detected.
Closes gh-25901
Previously, the restart initializer that enables restart when
-Dspring.devtools.restart.enabled=true is set had no effect when the
ClassLoader's name did not contain AppClassLoader. This commit updates
RestartApplicationListener to use the correct RestartInitializer when
the system property has forcibly enabled restart.
When restart is enabled a SilentExitException is thrown and it should be
caught and handled by the SilentExitExceptionHandler. When the
application is invoked via one of the loader's LauncherClasses
reflection is used and this exception becomes wrapped in an
InvocationTargetEception. Previously, this wrapping prevented
SilentExitExceptionHandler from handling the exception. This commit
updates the handler to look for an InvocationTargetException with a
SilentExitException target in addition to continuing to look for a
SilentExitException directly.
Fixes gh-24797
Replace `WebSecurityConfigurer` and `WebSecurityConfigurerAdapter`
configurations with `WebSecurityCustomizer` or `SecurityFilterChain`
beans.
Closes gh-23421
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
Add a simple `BootstrapRegistry` that can be used to store and share
object instances across `EnvironmentPostProcessors`. The registry
can be injected into the constructor of any `EnvironmentPostProcessor`.
Registrations can also perform additional actions when the
`ApplicationContext` has been prepared. For example, they could register
the the bootstrap instances as beans so that they become available to
the application.
See gh-22956
Previously, waitsForQuietPeriod would iterate 10 times, touching a new
file and then sleeping for 100ms at it did so. With a quiet period of
200ms, this was intended to result in a single change set containing
10 files. However, the test would fail occasionally as multiple change
sets were detected. The test is multi-threaded and is, therefore, at
the mercy of the scheduler. If the thread that is iterating and
touching the files takes over 200ms to be scheduled – exceeding the
watcher's quiet period – the watcher may detect a change set while the
changes are still being made. Eliminating this possibilty would require
the test to participate in the watcher's synchronization, which would
require some changes to its implementation. Instead, this commit
aims to avoid the problem by sleeping for 1/10 of the time (10ms) and
expecting a single change set of 100 files. The hope is that the much
shorter sleep time will result in the file touching thread being
scheduled well within the 200ms quiet period.
Closes gh-22732
Update `EnvironmentPostProcessorApplicationListener` so that it can
either use values from `spring.factories` or use a factory interface.
Closes gh-22529
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
Prior to this commit, there was a property server.error.include-details
that allowed configuration of the message and errors attributes in a
server error response.
This commit separates the control of the message and errors attributes
into two separate properties named server.error.include-message and
server.error.include-binding-errors. When the message attribute is
excluded from a servlet response, the value is changed from a
hard-coded text value to an empty value.
Fixes gh-20505
Andy Wilkinson
Phillip Webb
Stephane Nicoll
Artur Signell
Brian Clozel
Scott Frederick
Leo Li
dreis2211
bono007
sfeldstein
Francis Lavoie
weixsun
Madhura Bhave
izeye
Andy Wilkinson
Stephane Nicoll
XenoAmess
Tomek Szmytka
Scott Frederick
Phillip Webb