Previously, spring-boot-restclient was a required dependency of
spring-boot-resttestclient. This had the unwanted side-effect of
increasing the risk of the test classpath enabling auto-configuration
for RestClient.Builder when it was main code that needed such a bean.
This could lead to integration tests passing but the application
itself failing to start when its run through its main method.
This commit makes spring-boot-restclient an optional dependency of
spring-boot-resttestclient. As a result, a dependency on
spring-boot-resttestclient is no longer sufficient to auto-configure
a RestClient.Builder bean, although it is still sufficient to
auto-configure a RestTestClient bean.
Those that wish to use TestRestTemplate rather than migrating to
RestTestClient will now have to add a dependency on
spring-boot-restclient. This makes it presence more obvious. It now
has to be declared directly rather than being somewhat hidden due to
being pulled in transitively. The hope is that this will reduce the
chances of the dependency being accidentially on the test classpath
when main code requires it to be on the runtime classpath.
Fixes gh-48253
The ProblemDetailXmlMapperBuilderCustomizer applied the wrong
ProblemDetail mixin for the Jackson XmlMapper. Namely the
ProblemDetailJacksonMixin, which is intended for JSON.
Now the ProblemDetailJacksonXmlMixin is used instead.
The corresponding test also tested for the wrong XML output,
which has been adjusted.
Fixes gh-48222
Signed-off-by: Maurice Zeijen <mzeijen@bol.com>
Change `spring-boot-tomcat-runtime` and `spring-boot-jetty-runtime`
into starter POMs and reduce the number of dependencies needed for
`spring-boot-tomcat` and `spring-boot-jetty`.
The runtime starters provide only the jars required to run the
embedded server along with the module jar itself (excluding transitive
dependencies) and `spring-boot-webserver` (excluding transitive
dependencies).
The build setup required for an executable jar is slightly different
between Maven and Gradle. For Maven, the regular module is put in the
`provided` scope. For Gradle, the regular module remains in main
configuration and the runtime jar is put in the `providedRuntime`
configuration. The reference documentation has been updated to
show how to configure things if starters are being used.
Manual testing has been performed to ensure that wars build with Maven
and Gradle work with both Tomcat and Jetty in both deployed and
`java -jar` modes.
Closes gh-48175
This commit moves mime-mapping.properties in the module that actually
uses it, rather than in the top-level spring-boot module.
See gh-48138
Signed-off-by: Stefan Würsten <stefan@wuersten.ch>
This commit applies similar changes already contributed to the
`HttpMessageConverter` stack for MVC applications.
Since there was no auto-configuration for Kotlinx JSON Serialization on
the reactive side, this commit adds a relevant `CodecCustomizer` that
will use an available `Json` bean and use it to configure a codec that:
* will only consider `@Serializable`-annotated types if another JSON
library is available
* will use a broader support with Kotlinx Serialization otherwise
Fixes gh-48070
This commit ensures that XML and JSON converters on both client and
server are configured using the dedicated methods on
`HttpMessageConverters`, instead of pushing them ahead of default
converters.
Closes gh-47917
Fixes gh-48096
Tomcat 11 will [1] send a response as soon as Content-Length bytes has
been written. This initiates a race between the timer being registered
on the server side and the test receiving the response and looking for
the timer.
Rather than sleeping for a fix period of time, we now use Awaitility
to await the availability of the timer.
Closes gh-48049
[1] https://github.com/apache/tomcat/commit/69eff83577f7c00cbaaca9384ab4b1989f516797
Previously, Kotlin Serialization would be used too aggressively then
an alternative JSON converter was available. This could lead to
unwanted results when a response should have been serialized using
Jackson, for example, rather than Kotlin Serialization.
This commit addresses this by only allowing Kotlin Serialization to
serialize types that are not annotated with @Serializable when no
alternative JSON converter is available.
Fixes gh-48070
As of As of spring-projects/spring-framework#35733, Spring Framework has
a dedicated method for configuring a Kotlin Serialization converter
specifically.
This commit uses this method instead of configuring the Kotlin
Serialization JSON support as a custom converter. This also removes the
`@Order` on the Kotlin converter bean itself, as there is no need to
order it in the list of custom converters anymore.
Closes gh-47917
Stéphane Nicoll
Andy Wilkinson
Maurice Zeijen
michaldo
Phillip Webb
Moritz Halbritter
Steve Armstrong
Stefan Würsten
Brian Clozel