This commit maps the `server.servlet.session.cookie.same-site`
configuration property to the `DefaultCookieSerializer` bean configured
in the Spring Session auto-configuration.
See gh-28784
Update `ErrorPageSecurityFilterConfiguration` to guard against the case
where `spring-security-core` is on the classpath but
`spring-security-web` is not.
Fixes gh-28774
This commits exposes the RestClientBuilder as a bean even when the
RestHighLevelClient is not available. It allows users to create their
own RestClient beans using the Spring Boot configured RestClientBuilder
when they are not using the RestHighLevelClient.
Fixes gh-28655
Bean post-processors only apply to the context in which they're
registered. ValidationAutoConfiguration will only auto-configure the
MethodValidationPostProcessor if the post-processor is missing from
the current context and any of its ancestors. If an ancestor context
contains the post-processor it will not be auto-configured and the
descendant context will not have method validation configured.
This commit updates the auto-configuration to limit the search for
an existing MethodValidationPostProcessor bean to the current
context.
Fixes gh-27890
Update Tomcat, Jetty and Undertow `ServletWebServerFactory`
implementations so that they can write SameSite cookie attributes.
The session cookie will be customized whenever the
`server.servlet.session.cookie.same-site` property is set.
Other cookies can be customized with the new `CookieSameSiteSupplier`
interface which can be registered using `@Bean` methods.
Closes gh-20971
Co-authored-by Andy Wilkinson <wilkinsona@vmware.com>
Relocate the recently introduced `spring.webflux.session` properties
to `server.reactive.session` and create a unified `Cookie` properties
class.
Reactive session properties now mirror the existing
`server.servlet.session` properties and better reflect the fact that
they are related to the server and not just for WebFlux.
See gh-26714
Fix `WebFluxAutoConfigurationTests` following upstream Spring Framework
changes. Also refine `WebMvcAutoConfigurationTests` to check the locations
are set even if they are filtered.
See gh-28223
The `spring.integration.poller.fixed-rate` property must be set to the
constructor of the `PeriodicTrigger` and its `fixedRate` flag should be
set to `true`. The current code-base has it exactly opposite: the flag
is set to `true` when `fixed-delay` is provided.
* Fix `IntegrationAutoConfiguration.asTrigger()` method for the proper
`fixedRate` setting logic.
* Cover the change with a new test-case
* Add a message handling verification to the `defaultPoller()` test to
be sure that poller auto-configuration works as it is claimed.
See gh-28237
Spring Framework will filter non-existent locations from any configured
static resource handlers starting with 5.3.11. Tests that verify
static resource locations should account for this change.
See gh-28223
When polling consumers or source polling channel adapters are used in
Spring Integration applications, they require some polling policy to
be configured.
This comment auto-configures a PollerMetadata bean which customized
via newly added `spring.integration.poller.*` configuration
properties or overriden completely be user-defined bean.
See gh-27992
Previously, the detector for AbstractDataSourceInitializers used the
default detector order. This resulted in the initializers detected
initializers running before Flyway. Constrastingly, the detector for
DataSourceScriptDatabaseInitializers uses a custom order so its
detected initializers would run after Flyway.
This commit aligns the order of the detector for
AbstractDataSourceInitializers with the order of the detector for
DataSourceScriptDatabaseInitializers. This ensures that script-based
initialization runs in the same order with respect to Flyway,
irrespective of which initializer implementation is driving it.
Fixes gh-28079
Previously, a number of Elasticsearch properties were duplicated
across the spring.elasticsearch.rest and
spring.data.elasticsearch.client.reactive prefixes for configuring
the blocking REST client provided by Elasticsearch and the reactive
client provided by Spring Data respectively. This could cause
problems when using the Elasticsearch REST client configured with
a custom spring.elasticsearch.rest.uris. If Spring WebFlux (to make
use of WebClient) and Spring Data Elasticsearch were on the classpath,
the reactive Elasticsearch Client would be autoconfigured but it
would use the default value of its analogous
spring.data.elasticsearch.client.reactive.endpoints property. It
would be unable to connect, causing a startup failure.
This commit consoliates the configuration properties where possible.
Each setting that is common across the two clients is now configured
using a single, shared spring.elasticsearch property. Each setting
that is specific to the blocked REST client or the WebClient-based
reactive client now have prefixes of spring.elasticsearch.restclient
and spring.elasticsearch.webclient respectively.
The old properties beneath spring.elasticsearch.rest and
spring.data.elasticsearch.client.reactive have been deprecated. If a
any deprecated property is set, all of the new properties are
ignored. In other words, to migrate to the new properties, each usage
of a now-deprecated property must be updated to use its new
replacement instead.
Closes gh-23106
`ErrorHandler/BatchErrorHandler` will be deprecated in a future release
in favor of `CommonErrorHandler`. Currently, the legacy handlers are
adapted to a `CommonErrorHandler` or ignored if a `CommonErrorHandler`
is configured.
See gh-27927
Stephane Nicoll
Vedran Pavic
Stefano Cordio
Željko Tomić
Phillip Webb
Madhura Bhave
Andy Wilkinson
Filip Hrisafov
Josh Cummings
izeye
Leo Li
weixsun
Tim te Beek
Bartosz Jaszczak
Artem Bilan
StitzL
Scott Frederick
Anjee
Dąbrowski
Eddú Meléndez
dreis2211
Gary Russell