Any classes that rely on Spring Data being on the classpath
have been moved under a data package.
Certain configuration properties have also been updated to
accurately reflect whether Spring Data is required for the
auto-configuration to work.
Closes gh-11574
This commit adds the Spring for GraphQL auto-configuration back
into Spring Boot 3.0, now that a 1.1.0 release is scheduled with the
required baseline. This release also needs GraphQL Java 19.0 as a
baseline.
Closes gh-31809
We have hazelcast configuration files that are used with multiple
versions of Hazelcast. Version 3's scheme doesn't allow us to set
<auto-detection enabled="false" />. To work around this, we
configure a system property that causes Hazelcast to disable schema
validation.
See gh-38163
This only registers the default locations, not the one users can provide
via 'spring.sql.init.schema-locations' and
'spring.sql.init.data-locations'.
Closes gh-31533
This commit introduces auto-configuration for the new Elasticsearch
clients that are based upon their new Java client. The new Java
client builds on top of their existing low-level REST client,
replacing the high-level REST client which has been deprecated.
As part of introducing support for the new Elasticsearch client,
the auto-configuration for the templates (both imperative and
reactive) provided by Spring Data has also been updated to use the
new templates that build upon the new Java client.
As part of these changes, support for the high-level REST client and
the old Spring Data Elasticsearch templates has been removed. One
significant change is that the new reactive template is no longer
based on WebClient. As a result, the WebClient-specific configuration
property has been removed.
Closes gh-30647
Closes gh-28597
Closes gh-31755
With the 1.0 release of the SPI, R2DBC's bom is no longer published.
This commit updates Spring Boot's dependency management to no longer
use the bom. Tests have also been updated to adapt to slight changes
in R2DBC's configuration options and their default values.
Closes gh-31702
Spring Security now filters every dispatch by default and not only
once-per-request. Security configuration has been updated in a number of
places to restore the old behavior as needed for the tests to pass.
gh-31703 has been opened to review this and to investigate if we can
now remove the error page security filter and rely on the filtering of
every dispatch instead.
In addition to switching to once-per-request filtering where needed,
this commit also restructures the configuration of the error page
security filter. The restructuring was necessary to ensure that the
privilege evaluator bean has been defined before the conditions on the
error page security filter are evaluated. Without the change, the filter
was no longer being configured as the privilege evaluator hadn't been
defined before the on bean condition was evaluated. We may want to back
port this change as the ordering doesn't appear to have been defined
before and we were just getting lucky.
See gh-31622
See spring-projects/spring-security#11466
Andy Wilkinson
Madhura Bhave
Johnny Lim
Brian Clozel
Stephane Nicoll
Phillip Webb
Kalpesh
Adrian Bob
Marc Wrobel
Vedran Pavic
lihan
aoyvx
Moritz Halbritter
Michael Kreis