From c209b6700a78dc8ed1a20919d012377acdb05e50 Mon Sep 17 00:00:00 2001 From: Rossen Stoyanchev Date: Wed, 12 Dec 2012 12:33:47 -0500 Subject: [PATCH] Update reference docs on content negotiation config --- src/reference/docbook/mvc.xml | 64 ++++++++++++++++++++++------ src/reference/docbook/new-in-3.2.xml | 20 +++------ 2 files changed, 57 insertions(+), 27 deletions(-) diff --git a/src/reference/docbook/mvc.xml b/src/reference/docbook/mvc.xml index 3007fd9b76f..3225df34656 100644 --- a/src/reference/docbook/mvc.xml +++ b/src/reference/docbook/mvc.xml @@ -5023,17 +5023,27 @@ public class WebConfig extends WebMvcConfigurerAdapter {
Configuring Content Negotiation - You can configure how Spring MVC determines requested media types for content negotiation purposes. - The available strategies are to check the request path extension, a - request parameter, the "Accept" header, and also to use a default content type. - - By default the path extension is checked first and the "Accept" - header is checked second. The path extension check recognizes ".json" if Jackson is available, - ".xml" if JAXB2 is available, and ".atom" and ".rss" if the Rome library is available. - It also uses the ServletContext and the Java Activation Framework - to perform lookups as a fallback option. - - An example of customizing content negotiation in Java: + Staring with Spring Framework 3.2, you can configure how Spring MVC + determines the requested media types from the client for request mapping + as well as for content negotiation purposes. The available options are + to check the file extension in the request URI, the "Accept" header, + a request parameter, as well as to fall back on a default content type. + By default, file extension in the request URI is checked first and + the "Accept" header is checked next. + + For file extensions in the request URI, the MVC Java config and + the MVC namespace, automatically register extensions such as + .json, .xml, + .rss, and .atom if the + corresponding dependencies such as Jackson, JAXB2, or Rome + are present on the classpath. Additional extensions may be not need + to be registered explicitly if they can be discovered via + ServletContext.getMimeType(String) or the + Java Activation Framework + (see javax.activation.MimetypesFileTypeMap). + + Below is an example of customizing content negotiation + options through the MVC Java config: @Configuration @EnableWebMvc @@ -5045,10 +5055,12 @@ public class WebConfig extends WebMvcConfigurerAdapter { } } - In XML you'll need to use the content-negotiation-manager - property of annotation-driven: + In the MVC namespace, the <mvc:annotation-driven> element + has a content-negotiation-manager attribute, which expects a + ContentNegotiationManager that in turn can be created + with a ContentNegotiationManagerFactoryBean: - <mvc:annotation-driven content-negotiation-manager="contentNegotiationManager" /> + <mvc:annotation-driven content-negotiation-manager="contentNegotiationManager" /> <bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean"> <property name="favorPathExtension" value="false" /> @@ -5061,6 +5073,30 @@ public class WebConfig extends WebMvcConfigurerAdapter { </property> </bean> + If not using the MVC Java config or the MVC namespace, you'll need + to create an instance of ContentNegotiationManager + and use it to configure + RequestMappingHandlerMapping 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. + + In more advanced cases, it may be useful to configure + multiple ContentNegotiationManager instances + that in turn may contain custom + ContentNegotiationStrategy implementations. + For example you could configure + ExceptionHandlerExceptionResolver with + a ContentNegotiationManager that always + resolves the requested media type to "application/json". + Or you may want to plug a custom strategy that has some logic to select + a default content type (e.g. either XML or JSON) if no content + types were requested. +
diff --git a/src/reference/docbook/new-in-3.2.xml b/src/reference/docbook/new-in-3.2.xml index 6b5dcc47fda..3451aba6120 100644 --- a/src/reference/docbook/new-in-3.2.xml +++ b/src/reference/docbook/new-in-3.2.xml @@ -56,26 +56,20 @@ A ContentNeogtiationStrategy is now available for resolving the requested media types from an incoming - request. The available implementations are based on path extension, - request parameter, 'Accept' header, and a fixed default content type. + request. The available implementations are based on the file extension, + query parameter, the 'Accept' header, or a fixed content type. Equivalent options were previously available only in the ContentNegotiatingViewResolver but are now available throughout. ContentNegotiationManager is the central - class to use when configuring content negotiation options. It accepts one - or more ContentNeogtiationStrategy instances and delegates to them. It can - be plugged into RequestMappingHandlerMapping, - RequestMappingHandlerAdapter, - ExceptionHandlerExceptionResolver, and - ContentNegotiatingViewResolver. The MVC namespace - and the MVC JavaConfig provide convenient options to configure all - that. + class to use when configuring content negotiation options. + For more details see . The introduction of ContentNegotiationManger - also enables smart suffix pattern matching for incoming requests. See + also enables selective suffix pattern matching for incoming requests. + For more details, see the Javadoc of commit - message. + xl:href="http://static.springsource.org/spring-framework/docs/3.2.0.BUILD-SNAPSHOT/api/org/springframework/web/servlet/mvc/method/annotation/RequestMappingHandlerMapping.html#setUseRegisteredSuffixPatternMatch(boolean)">RequestMappingHandlerMapping.setUseRegisteredSuffixPatternMatch.