Before this fix the q-value of media types in the Accept header were
ignored when using the new RequestMappingHandlerAdapter in combination
with @ResponseBody and HttpMessageConverters.
Issue: SPR-9160
Backport-Issue: SPR-9168
Backport-Commit: 982cb2f258a5be1173115044d379f54702dc8c5b
The MappingJacksonHttpMessageConverter now catches all IOException
types raised while reading JSON and translates them into
HttpMessageNotReadableException.
Issue: SPR-9238
Backport-Issue: SPR-9397
Backport-Commit: 816c1f47a4a9638d9442b5060312a6b2082eb7b1
Jackson 2 uses completely new package names and new maven artifact ids.
This change adds Jackson 2 as an optional dependency and also provides
MappingJackson2HttpMessageConverter and MappingJackson2JsonView for use
with the new version.
The MVC namespace and the MVC Java config detect and use
MappingJackson2HttpMessageConverter if Jackson 2 is present.
Otherwise if Jackson 1.x is present,
then MappingJacksonHttpMessageConverter is used.
Issue: SPR-9302
Backport-Issue: SPR-9507
Backport-Commit: e63ca04fdb1e01689d0d5c38ffae5991bde2ebd2
Invalid Content-Type or Accept header values previously resulted in the
IllegalArgumentException getting propagated. After this change such
errors are detected and generally treated as a "no match", which
may for example result in a 406 in the case of the Accept header.
Issue: SPR-9142
Backport-Issue: SPR-9148
Backport-Commit: ca8b98e94724cd9a2008deb4fe1280aaace6ca8b
The contents of this file could be problematic as they were generated
by spring-build with "org.springframework.core.jar" EBR-style naming,
but this naming is incorrect when dealing with Maven-central style
artifacts, e.g. spring-core.jar.
While a well-formed INDEX.LIST may speed up classloading, the simplest
solution to the issues listed below is simply to eliminate the file.
This also means consistent treatment across 3.1.x and 3.2.x artifacts,
as the new Gradle build in 3.2.x does not create these index files.
Issue: SPR-6383, SPR-9208
ServletServerHttpRequest now falls back on the contentType and the
the characterEncoding of the ServletRequest, if the headers of the
incoming request don't specify one. Similary ServletServerHttpResponse
sets the contentType and the characterEncoding of the ServletResponse
if not already set.
This allows using the CharacterEncodingFilter to set a character
encoding where the request doesn't specify one and have it be used
in HttpMessageConverter's.
SPR-9096
Although the reference documentation listed the new @MVC support
classes and their benefits, it did not explicitly mention a few
use cases that are no longer supported. There is now a specific
section on the new support classes listing exactly what is not
supported.
Similary the @RequestMapping annotation never refered explicitly
to the existence of old and new support and never made it clear
exactly what the differences are.
Both have not been corrected.
SPR-9063, SPR-9042
A list of "known" session attributes (listed in @SessionAttributes)
was gradually built as attributes get added to the model. In a
failover scenario that knowledge is lost causing session attributes
to be potentially re-initialized via @ModelAttribute methods.
With this change @SessionAttributes listed by name are immediately
added to he list of "known" session attributes thus this knowledge
is not lost after a failover. Attributes listed by type however
still must be discovered as they get added to the model.
The "default" FlashMapManager implementation added in 3.1 was invoked
after the redirect, which is too late in cases where the HTTP session
has not been yet been created since as the response is committed.
This change corrects the issue and makes other improvements to the
FlashMapManager implementation such as extracting a base
AbstractFlashMapManager class and making it easier for other
implementations to be added (for example cookie-based).
A direct path match with incorrect HTTP request method was causing another
request mapping with a pattern and a correct HTTP method to be ignored.
The bug affects the new @MVC support classes
(i.e. RequestMappingHandlerMapping).
The AbstractHttpMessageConverter was using the requested Content-Type
rather than the actual response Content-Type to determine the length
of the content. This can lead to a problem when a controller returns
a ResponseEntity with a Content-Type header that ignores (overrides)
the requested Content-Type. The fix ensures that actual response
Content-Type is the one used both to write to the response and to
determine the length of the content.
The UriComponentsBuilder instance passed into the method is initialized
with current request information including host, scheme, port, context
path, and the servlet mapping's literal part.
Also added shortcut methods to buildAndExpand in UriComponentsBuilder.
The Content-Type header and the contentType field in HttpServletRequest/Response
are now always in sync. When a header is added the contentType field is updated
as well and vice versa.
Similarly when the Content-Type header or the contentType field includes a charset
field, the character encoding is updated and vice versa.
Rossen Stoyanchev
Juergen Hoeller
Chris Beams
Arjen Poutsma
Costin Leau
Sam Brannen