@ -2861,24 +2861,15 @@ representation of the current resource regardless of the logical view name. The
@@ -2861,24 +2861,15 @@ representation of the current resource regardless of the logical view name. The
header may include wild cards, for example `text/{asterisk}`, in which case a `View` whose
Content-Type was `text/xml` is a compatible match.
To support the resolution of a view based on a file extension, use the
`ContentNegotiatingViewResolver` bean property `mediaTypes` to specify a mapping of file
extensions to media types. For more information on the algorithm used to determine the
request media type, refer to the API documentation for `ContentNegotiatingViewResolver`.
To support custom resolution of a view based on a file extension, use a
`ContentNegotiationManager`: see <<mvc-config-content-negotiation>>.
Here is an example configuration of a `ContentNegotiatingViewResolver:`
Here is an example configuration of a `ContentNegotiatingViewResolver`:
@ -2890,7 +2881,7 @@ Here is an example configuration of a `ContentNegotiatingViewResolver:`
@@ -2890,7 +2881,7 @@ Here is an example configuration of a `ContentNegotiatingViewResolver:`
@ -4867,9 +4858,9 @@ that in turn can be created with a `ContentNegotiationManagerFactoryBean`:
@@ -4867,9 +4858,9 @@ that in turn can be created with a `ContentNegotiationManagerFactoryBean`:
@ -4884,7 +4875,7 @@ for request mapping purposes, and `RequestMappingHandlerAdapter` and
@@ -4884,7 +4875,7 @@ for request mapping purposes, and `RequestMappingHandlerAdapter` and
`ExceptionHandlerExceptionResolver` for content negotiation purposes.
Note that `ContentNegotiatingViewResolver` now can also be configured with a
`ContentNegotiatingViewResolver`, so you can use one instance throughout Spring MVC.
`ContentNegotiationManager`, so you can use one shared instance throughout Spring MVC.
In more advanced cases, it may be useful to configure multiple
`ContentNegotiationManager` instances that in turn may contain custom