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
Introduce a strategy to `WebApplicationType` to allow modules to
implement deduction logic.
Prior to this commit, modules played no part in deducing the
`WebApplicationType`. This meant that a user with `spring-webflux`
for client purposes would deduce `REACTIVE` despite no
`spring-boot-webflux` module being present.
The following deduction logic order is now implemented:
1) If the `spring-boot-webmvc` module is being used and Spring MVC
classes are found then `SERVLET` is used.
2) If the `spring-boot-webflux` module is being used and Spring WebFlux
classes are found then `REACTIVE` is used.
3) If `spring-web` is found and servlet classes are available then
`SERVLET` is used.
4) If none of the above are satisfied, `NONE` is used.
This commit also updates `SpringBootTestContextBootstrapper` to use
the same deduction logic.
Fixes gh-48517
Mirror the package names used in actuator for classes to support
mappings and exchanges in `spring-boot-servlet`, `spring-boot-webmvc`
and `spring-boot-webflux`.
Closes gh-46217
This commit modularizes spring-boot-test-autoconfigure. It now
contains only the code that's central to test auto-configuration.
Feature-specific functionality has moved out into -test modules,
some existing and some newly created. For example, `@DataJpaTest` can
now be found in spring-boot-data-jpa-test.
Closes gh-47322
Refactor `PropertyMapper` so that it no longer calls adapter or
predicate methods by default when the source value is `null`. This
effectively makes all default calls the same as using
`alwaysWhenNotNull` in the previous generation of the code.
For the limited times when you do need to deal with `null` values, the
new `always()` method can be used.
For example,
map.from(source::method).to(destination::method);
Will not call `destination.method(...)` if `source.method()` returns
`null`.
Where as:
map.from(source::method).always().to(destination::method);
Will call `destination.method(null)` if `source.method()` returns
`null`.
This update provides clearer semantics for the API and allows for better
JSpecify nullability annotations. It has also simplified much of our
existing property mapper code.
Closes gh-47024
Co-authored-by: Moritz Halbritter <moritz.halbritter@broadcom.com>
The enum itself is not specifically tied to auto-configuration so
spring-boot is a better place for it. The related condition,
`@ConditionalOnThreading`, remains in spring-boot-autoconfigure. This
aligns things with the similar `CloudPlatform` and
`@ConditionalOnCloudPlatform`.
Closes gh-46406
Moritz Halbritter
Stéphane Nicoll
husseinvr97
Andy Wilkinson
Phillip Webb
Moritz Halbritter