Prior to this change, VersionResourceResolver and VersionStrategy would
resolve static resources using version strings. They assist
ResourceHttpRequestHandler with serving static resources. The
RequestHandler itself can be configured with HTTP caching strategies to
set Cache-Control headers.
In order to have a complete strategy with Cache-Control and ETag
response headers, developers can't reuse that version string information
and have to rely on other mechanisms (like ShallowEtagHeaderFilter).
This commit makes VersionResourceResolver use that version string to set
it as a request attribute, which will be used by the
ResourceHttpRequestHandler to write an ETag response header.
Issue: SPR-13382
Prior to this change, ResourceUrlEncodingFilter and ResourceUrlProvider
would try to resolve the resource path using the full request URL (i.e.
request path and request parameters), whereas the request path is the
only information to consider.
This would lead to StringIndexOutOfBoundsExceptions when the path +
request params information was given to the AntPathMatcher.
This commit makes the appropriate change to both
ResourceUrlEncodingFilter and ResourceUrlProvider, in order to only
select the request path.
Issue: SPR-13374
This commit introduces the following changes:
- Content type can now be properly configured
- Default content type is "text/html"
- Content type and charset are now properly set in the response
Issue: SPR-13379
Prior to this change, trying to set an unquoted ETag with
`ResponseEntity`'s API would throw an `IllegalArgumentException`.
This commit automatically quotes ETag values set using ResponseEntity.
Issue: SPR-13378
In an attempt to make our Jetty-based integration tests more robust,
this commit discontinues use of SocketUtils for picking a random,
available port and instead lets the Jetty Server pick its own port.
The StompSubProtcolHandler now checks the outcome of the send to the
inbound client channel. If the message was prevented from being sent,
e.g. as part of authorization, events are not published
Issue: SPR-13339
Before this commit RequestPartServletServerHttpRequest simply did an
instanceof check for MultipartHttpServletRequest. That hasn't failed
because request wrapping typically happens in filters before the
DispatcherServlet calls the MultipartResolver.
With Spring MVC Test and the Spring Security integraiton however,
this order is reversed since there we prepare the multipart request
upfront, i.e. there is no actual parsing.
The commit unwraps the request if necessary.
Issue: SPR-13317
Prior to this commit, EmbeddedDatabaseFactory logged the name of an
embedded database just before it was created; however, the name alone
is not sufficient for connecting to the database via external tools
such as the H2 Web Console.
This commit updates EmbeddedDatabaseFactory to make it easier to
connect to embedded databases via external tools by logging the
complete connection URL for an embedded database as it's being created.
In addition, EmbeddedDatabaseFactory now logs when an embedded database
is being shut down.
Issue: SPR-13370
Instead of having to use the default constructor then calling
setObjectMapper(ObjectMapper), these constructors allow
MappingJackson2JsonView and MappingJackson2XmlView to be created and
configured with the desired object mapper in one step.
This commit introduces new `isEmpty()` and `isNotEmpty()` methods in
`JsonPathResultMatchers` and `JsonPathRequestMatchers` which delegate
to the new `assertValueIsEmpty()` and `assertValueIsNotEmpty()` methods
in `JsonPathExpectationsHelper`, respectively.
Issue: SPR-13352
Commit fffdd1e9e9 introduced additional
JsonPath result matchers in JsonPathResultMatchers for server-side
testing of MVC controllers.
This commit introduces comparable methods in JsonPathRequestMatchers
for client-side testing with a RestTemplate.
- isString()
- isBoolean()
- isNumber()
- isMap()
Issue: SPR-13320
Prior to this commit, the exists() method in JsonPathExpectationsHelper
correctly asserted that the evaluated JsonPath expression resulted in a
value (i.e., that a non-null value exists); however, if the value was
an empty array, the exists() method always threw an AssertionError.
The existing behavior makes sense if the JsonPath expression is
'indefinite' -- for example, if the expression uses a filter to select
results based on a predicate for which there is no match in the JSON
document, but the existing behavior is illogical and therefore invalid
if the JsonPath expression is 'definite' (i.e., directly references an
array in the JSON document that exists but happens to be empty). For
example, prior to this commit, the following threw an AssertionError.
new JsonPathExpectationsHelper("$.arr").exists("{ 'arr': [] }");
Similar arguments can be made for the doesNotExist() method.
After thorough analysis of the status quo, it has become apparent that
the existing specialized treatment of arrays is a result of the fact
that the JsonPath library always returns an empty list if the path is
an 'indefinite' path that does not evaluate to a specific result.
Consult the discussion on "What is Returned When?" in the JsonPath
documentation for details:
https://github.com/jayway/JsonPath#what-is-returned-when
This commit addresses these issues by ensuring that empty arrays are
considered existent if the JsonPath expression is definite but
nonexistent if the expression is indefinite.
Issue: SPR-13351
Juergen Hoeller
Brian Clozel
Sebastien Deleuze
Sam Brannen
Rossen Stoyanchev
Stephane Nicoll
xueyua
Craig Andrews
Paul Verest
Kazuki Shimizu