Tomcat 9.0.115, 10.1.52, and 11.0.18 include a breaking change [1] to
how ciphers are configured when using HTTPS. Previously, a single
setting was used but this has now been split in two; the existing
ciphers setting for TLSv1.2 ciphers and a new ciperSuites setting for
TLSv1.3. As part of this split, the behavior of the ciphers setting
has been changed such that any TLSv1.3 ciphers are ignored and a
warning is logged.
This change in Tomcat is problematic without also making some changes
in Boot. If we had done nothing, a user that had configured only
TLSv1.3 cipers would have them all ignored, leaving their SSL
connection unexpectedly using all of the default ciphers which may be
less secure.
This commit adapts to the breaking change in Tomcat by taking the
user's list of ciphers and splitting into into TLSv1.2 and TLSv1.3
ciphers before passing them into Tomcat's two settings (ciphers and
cipherSuites respectively). This is done defensively for backwards
compatibility. If the methods to identify and configure the TLSv1.3
ciphers are not present, we assume that we're running with an earlier
version of Tomcat and fall back to passing them all into the ciphers
setting as we did previously.
Closes gh-49143
[1] 9abf6bddb2
Tomcat 9.0.115, 10.1.52, and 11.0.18 include a breaking change [1] to
how ciphers are configured when using HTTPS. Previously, a single
setting was used but this has now been split in two; the existing
ciphers setting for TLSv1.2 ciphers and a new ciperSuites setting for
TLSv1.3. As part of this split, the behavior of the ciphers setting
has been changed such that any TLSv1.3 ciphers are ignored and a
warning is logged.
This change in Tomcat is problematic without also making some changes
in Boot. If we had done nothing, a user that had configured only
TLSv1.3 cipers would have them all ignored, leaving their SSL
connection unexpectedly using all of the default ciphers which may be
less secure.
This commit adapts to the breaking change in Tomcat by taking the
user's list of ciphers and splitting into into TLSv1.2 and TLSv1.3
ciphers before passing them into Tomcat's two settings (ciphers and
cipherSuites respectively). This is done defensively for backwards
compatibility. If the methods to identify and configure the TLSv1.3
ciphers are not present, we assume that we're running with an earlier
version of Tomcat and fall back to passing them all into the ciphers
setting as we did previously.
Closes gh-49108
[1] 9abf6bddb2
Prior to this commit, the `XmlMapper` auto-configuration for Jackson2
would refer to Jackson3's `XmlMapper` instead of Jackson2. This would
not only make the condition invalid, but it could also lead to
`NoClassDefFoundError` at runtime if the application mixed Jackson 2 and
3 on the classpath.
Fixes gh-49015
In addition to the upgrade, this commit also fixes some contract
violations in non-public APIs that are now detected as the new
version of the plugin enables contract checking by default.
Closes gh-49000
This automatically registers KafkaListenerObservationConvention on the
container factory, and KafkaTemplateObservationConvention on the
Kafka template.
Closes gh-48914
The condition is unnecessary as the sniifer is now included in the
same jar as the REST client itself.
See gh-48900
Signed-off-by: Johnny Lim <izeye@naver.com>
This commit adds the missing returnBodyOnDelete property to
DataRestProperties, completing the symmetric configuration for
controlling response body behavior across all CRUD operations.
The property maps to RepositoryRestConfiguration.setReturnBodyOnDelete()
which was added in Spring Data REST 4.1.
Signed-off-by: paullee714 <woolba714@kakao.com>
See gh-48872
spring-kafka has an api dependency on spring-tx, placing
the latter on the compile classpath of the former's consumers.
Additionally, when spring.kafka.producer.transaction-id-prefix is
set, the Kafka auto-configuration will define a Kafka-based
transaction manager. However, the transaction manager won't be used
without some configuration from the user as there's no dependency on
spring-boot-transaction and, therefore, no auto-configuration of
@EnableTransactionManagement.
This commit adds a spring-boot-transaction dependency to
spring-boot-kafka, aligning it with the spring-tx dependency that
spring-kafka already has.
Fixes gh-48880
Previously, MockRestServiceServerAutoConfiguration unconditionally
defined its beans, preventing the user from providing an alternative.
This commit adds @ConditionalOnMissingBean to ensure the auto-configuration
backs off when a user-provided alternatives are present.
See gh-48825
Signed-off-by: HuitaePark <qkrgmlxo3174@gmail.com>
Remove the `always()` call from the same site mapping and replace `as`
with a direct call. This update means that mapping only occurs when
`getSameSite` is not `null`, but mapping can still be applied if
`sameSite.getAttributeValue()` returns `null`.
Closes gh-48830
Following modularization, a presence check for ValidatorAdapter was
needed in the MVC and WebFlux auto-configuratiomn when creating
their Validators. Runtime hints to allow this check to work in a
native image were not added at the same time, resulting in the
class appearing to be absent. This caused message interpolation
for constraint violations to fail as newly created Validator was
being used which lacked the necessary MessageInterpolator
configuration.
This commit adds reflection hints for ValidatorAdapter, allowing
re-use of the context's main validator as the MVC and WebFlux
validators.
Fixes gh-48828
Spring Projects that have the `spring.graphql.schema.locations` property
set to `"classpath*:graphql/**/"` as suggested in the documentation have
failing GraphQL tests after upgrading to Spring Boot 4.
The `Query` type definition in the books-domain schema clashes with the
schema of the application. Presumably the books-domain schema was never
meant to exist in the exported JAR file. This commit moves it into the
test module to stop it from being exported and causing problems.
Signed-off-by: mspiess <30656914+mspiess@users.noreply.github.com>
See gh-48829
Previously, CloudFoundryActuatorAutoConfiguration required
RestTemplateBuilder, using it to create the RestTemplate that's used
the security interceptor. Following the modularization,
RestTemplateBuilder is only present when spring-boot-restclient is on
the classpath. In its absence, CloudFoundryActuatorAutoConfiguration
would fail.
This commit address this problem by using RestClient.Builder (and
RestClient) instead of RestTemplateBuilder (and RestTemplate). This
allows CloudFoundryActuatorAutoConfiguration to work without
spring-boot-restclient as RestClient.Builder and RestClient are
provided by spring-web that will always be there in an MVC webapp.
Fixes gh-48826
The built-in decompression support in HttpClient 5.6 breaks
Elasticsearch's Rest5Client as it results in double decompression.
The first decompression is performed by the Apache HTTP client. It
succeeds. The Elasticsearch Rest5Client then sees the
Content-Encoding: gzip header and makes a second attempt to inflate
the data. This fails as it has already been inflated.
Closes gh-48743
Andy Wilkinson
Eddú Meléndez
Stéphane Nicoll
Phillip Webb
Beom Su
Brian Clozel
Moritz Halbritter
Joaquin Santana
Yanming Zhou
jdsalasca
Johnny Lim
michaldo
paullee714
HuitaePark
mspiess