This commit makes sure that if a `Validator` is auto-configured, it is
reused as the `webFluxValidator`. This is pretty much the same thing as
what was done recently for Spring MVC.
Since the infrastructure is now shared, the package protected class has
been published in the `.validation` package.
Closes gh-8400
An `HttpHandler` bean must be provided once the infrastructure triggered
by `@EnableWebFlux` has been processed. Rather than creating a
`HttpHandler` in that auto-configuration, this commit moves it to a
dedicated auto-config, like we do for `DispatcherServlet` for
servlet-based webapps.
As this is the only bean we auto-configure in a functional fashion, the
`WebFluxFunctionalAutoConfiguration` is now merged with this new
auto-configuration, making its purposes clearer.
Cloess gh-8436
Previously, reflection was used to set the OBJENESIS field of
DummyInvocationUtils with an Objenesis instance that does not use
caching. This has stopped working as the field is now declared final.
This commit updates the approach take by HateoasObjenesisCacheDisabler
to disable Objenesis's cache. Rather than changing the value of the
OBJENESIS field on DummyInvocationUtils, the cache field on the
ObjenesisStd instance is set to null instead. This has the desired
effect of disabling Objenesis's caching.
See gh-3784
Closes gh-8335
Rework Spring MVC JSR-303 validation support a little more to move
most of the creation logic to the wrapper class. Also rename
`SpringValidatorAdapterWrapper` -> `WebMvcValidator`.
See gh-8223
This commit improves the initial solution by actually overriding the
`mvcValidator` `@Bean`. This gives us more control as whether a custom
validator has been specified or not. We now wrap it regardless of it
being custom or provided by auto-configuration.
Closes gh-8223
`MethodValidationPostProcessor` requires a `Validator` so we need to flag
it as an infrastructure bean to prevent an additional log that indicates
it won't be post-processed.
We obviously don't want to post-process the `Validator` here so adding the
additional meta-data is a good idea anyway.
Closes gh-8422
This commit add mock support for WebFlux with an infrastructure similar
to what `WebMvcTest` provides. `@WebFluxTest` can be used to test
controllers with a narrowed classpath that is relevant to WebFlux. Also,
`@SpringBootTest` now starts WebFlux in "mock" mode by default and
`@AutoConfigureWebTestClient` can be used to inject a `WebTestClient`
connected to the `ApplicationContext`.
To make that happen, a `ReactiveWebApplicationContext` interface has been
introduced to mirror what `WebApplicationContext` currently does. Things
are still a bit volatile at this point and that infra may move to Spring
Framework at some point.
Closes gh-8401
The server's session can now be configured in both a servlet and a
reactive environment. The latter has not requirement on the servlet API
and this commit removes the requirement to the `SessionTrackingMode`
enum.
Closes gh-8402
This commit exposes a `WebTestClient` automatically in a reactive
integration test that uses an embedded web server. This is similar to
what we do with `TestRestTemplate` for servlet based integration tests.
Closes gh-8399
This commit makes sure that `@SpringBootTest` with a reactive setup
starts a web application if necessary.
If both a servlet and a reactive environment are available, a servlet
environment is bootstraped. This commit also adds a way to force a
reactive environment by specifying the `spring.main.web-application-type`
property of the test (e.g. `@TestPropertySource`).
Closes gh-8383
This commit creates auto-configuration classes for both the
annotation and functional variants of the WebFlux framework.
They provide the basic support to get started with those, by
creating the required `HttpHandler` using the provided application
context (for annotation) or `RouterFunction`s (for functional).
They do support `WebFilter` registration and a few advanced
features such as resource handling, `messageReaders|Writers`
and `ViewResolver` auto-registration.
Closes gh-8386
This commit adds the auto-configuration for creating reactive
`EmbeddedWebServer` instances. This adds support for the
following servers: Reactor Netty, Tomcat, Jetty and Undertow.
Fixes gh-8302
Fixes gh-8117
This commit refactors the `EmbeddedWebServerInitializedEvent` hierarchy
to have one specialized event for Servlet based apps and another one for
reactive apps.
Each event implementation has:
* a specific `ApplicationContext` implementation for the app
* a custom `getServerId` implementation that differentiates the
application server from the management server
Closes gh-8348
This commit adds an `EmbeddedWebServer` instance to the
`ReactiveWebApplicationContext` and ties it to the application
lifecycle.
To launch a reactive web application, two elements are required
from the context:
* a `ReactiveWebServerFactory` to create a server instance
* a `HttpHandler` instance to handle HTTP requests
Closes gh-8337
This commit adds the infrastructure for creating and customizing
reactive embedded web servers. Common configuration has been refactored
into the new `ConfigurableEmbeddedWebServer` interface.
See gh-8302
This commit makes sure that the Spring `Validator` used by the MVC
layer doesn't expose a JSR-303 contract, if any.
The default implementation of the `mvcValidator` is
`LocalValidatorFactoryBean`. While this object is exposed as a Spring
`Validator` only, its runtime capabilities expose that contract as well
as the standard `Validator` and `ValidatorFactory` ones.
Concretely, if an auto-configuration is checking if a
`javax.validation.Validator` bean is missing, the condition will match
since we only know about "advertized types": beans haven't been created
yet so we can't inspect their runtime capabilities. Since the condition
match, we will auto-configure a bean. At runtime though, we're no longer
ale to inject a `javax.validation.Validator` by type since two candidates
are available.
This commit introduces `SpringValidatorAdapterWrapper`, a wrapper class
on any `SpringValidatorAdapter` (`LocalValidatorFactoryBean` being one of
the available implementations) that only exposes the Spring contract.
Also, if a `javax.validation.Validator` bean is available, we will use it
for the MVC layer, rather than creating a new one.
Closes gh-8223
Kazuki Shimizu
Stephane Nicoll
Andy Wilkinson
Phillip Webb
Brian Clozel