Previously, there were a number of inconsistencies in the embedded
containers' handling of static resources. The Servlet spec requires
that static resources can be served from the META-INF/resources/
directory of jars nested inside a war in WEB-INF/lib/. The intention
was also to extend this to cover jar packaging when jars are nested in
BOOT-INF/lib/. This worked when using Tomcat as long as Jasper was on
the classpath. If you didn't have Jasper on the classpath or you
were using Jetty or Undertow it did not work.
This commit updates the configuration of embedded Jetty, Tomcat, and
Undertow so that all three containers handle static resources in the
same way, serving them from jars in WEB-INF/lib/ or /BOOT-INF/lib/.
Numerous intergration tests have been added to verify the behaviour,
including tests for Tomcat 8.0 and 7.0 which is supported in addition
to the default 8.5.x. Note that static resource handling only works
with Jetty 9.3.x and 9.2 and earlier does not support nested jars (
see https://github.com/eclipse/jetty.project/issues/518 for details).
Closes gh-8299
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 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
Andy Wilkinson
Stephane Nicoll
erlholmq
Kazuki Shimizu
Phillip Webb