您好,登錄后才能下訂單哦!
小編給大家分享一下SpringMVC中如何使用消息轉換器HttpMessageConverter與@ResponseBody注解,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
本文使用的demo基于maven,是根據入門blog的例子繼續寫下去的。
我們先來看一看對應的現象。 我們這里的配置文件 *-dispatcher.xml中的關鍵配置如下:
(視圖配置省略)
<mvc:resources location="/static/" mapping="/static/**"/> <mvc:annotation-driven/> <context:component-scan base-package="org.format.demo.controller"/>
pom中需要有以下依賴(Spring依賴及其他依賴不顯示):
<dependency> <groupId>org.codehaus.jackson</groupId> jackson-core-asl <version>1.9.13</version> </dependency> <dependency> <groupId>org.codehaus.jackson</groupId> jackson-mapper-asl <version>1.9.13</version> </dependency>
這個依賴是json序列化的依賴。
ok。我們在Controller中添加一個method:
@RequestMapping("/xmlOrJson") @ResponseBody public Map
直接訪問地址:
我們看到,短短幾行配置。使用@ResponseBody注解之后,Controller返回的對象 自動被轉換成對應的json數據,在這里不得不感嘆SpringMVC的強大。
我們好像也沒看到具體的配置,唯一看到的就是*-dispatcher.xml中的一句配置: mvc:annotation-driven/。其實就是這個配置,導致了java對象自動轉換成json對象的現象。
那么spring到底是如何實現java對象到json對象的自動轉換的呢? 為什么轉換成了json數據,如果想轉換成xml數據,那該怎么辦?
**本文使用的spring版本是4.0.2。 **
在講解 mvc:annotation-driven/這個配置之前,我們先了解下Spring的消息轉換機制。@ResponseBody這個注解就是使用消息轉換機制,最終通過json的轉換器轉換成json數據的。
HttpMessageConverter接口就是Spring提供的http消息轉換接口。有關這方面的知識大家可以參考"參考資料"中的 第二條鏈接,里面講的很清楚。
下面開始分析 mvc:annotation-driven/這句配置:
這句代碼在spring中的解析類是:
在AnnotationDrivenBeanDefinitionParser源碼的152行parse方法中:
分別實例化了RequestMappingHandlerMapping,ConfigurableWebBindingInitializer,RequestMappingHandlerAdapter等諸多類。
其中RequestMappingHandlerMapping和RequestMappingHandlerAdapter這兩個類比較重要。
RequestMappingHandlerMapping處理請求映射的,處理@RequestMapping跟請求地址之間的關系。
RequestMappingHandlerAdapter是請求處理的適配器,也就是請求之后處理具體邏輯的執行,關系到哪個類的哪個方法以及轉換器等工作,這個類是我們講的重點,其中它的屬性messageConverters是本文要講的重點。
私有方法:getMessageConverters
從代碼中我們可以,RequestMappingHandlerAdapter設置messageConverters的邏輯:
1.如果 mvc:annotation-driven節點有子節點message-converters,那么它的轉換器屬性messageConverters也由這些子節點組成。
message-converters的子節點配置如下:
<mvc:annotation-driven> <mvc:message-converters> <bean class="org.example.MyHttpMessageConverter"/> <bean class="org.example.MyOtherHttpMessageConverter"/> </mvc:message-converters> </mvc:annotation-driven>
2.message-converters子節點不存在或它的屬性register-defaults為true的話,加入其他的轉換器:ByteArrayHttpMessageConverter、StringHttpMessageConverter、ResourceHttpMessageConverter等。
我們看到這么一段:
這些boolean屬性是哪里來的呢,它們是AnnotationDrivenBeanDefinitionParser的靜態變量。
其中ClassUtils中的isPresent方法如下:
看到這里,讀者應該明白了為什么本文一開始在pom文件中需要加入對應的jackson依賴,為了讓json轉換器jackson成為默認轉換器之一。
mvc:annotation-driven的作用讀者也明白了。
下面我們看如何通過消息轉換器將java對象進行轉換的。
RequestMappingHandlerAdapter在進行handle的時候,會委托給HandlerMethod(具體由子類ServletInvocableHandlerMethod處理)的invokeAndHandle方法進行處理,這個方法又轉接給HandlerMethodReturnValueHandlerComposite處理。
HandlerMethodReturnValueHandlerComposite維護了一個HandlerMethodReturnValueHandler列表。HandlerMethodReturnValueHandler是一個對返回值進行處理的策略接口,這個接口非常重要。關于這個接口的細節,請參考樓主的另外一篇博客:http://www.cnblogs.com/fangjian0423/p/springMVC-request-param-analysis.html。然后找到對應的HandlerMethodReturnValueHandler對結果值進行處理。
最終找到RequestResponseBodyMethodProcessor這個Handler(由于使用了@ResponseBody注解)。
RequestResponseBodyMethodProcessor的supportsReturnType方法:
然后使用handleReturnValue方法進行處理:
我們看到,這里使用了轉換器。
具體的轉換方法:
至于為何是請求頭部的Accept數據,讀者可以進去debug這個getAcceptableMediaTypes方法看看。 我就不羅嗦了~~~
ok。至此,我們走遍了所有的流程。
現在,回過頭來看。為什么一開始的demo輸出了json數據?
我們來分析吧。
由于我們只配置了 mvc:annotation-driven,因此使用spring默認的那些轉換器。
很明顯,我們看到了2個xml和1個json轉換器。 要看能不能轉換,得看HttpMessageConverter接口的public boolean canWrite(Class<?> clazz, MediaType mediaType)方法是否返回true來決定的。
我們先分析SourceHttpMessageConverter:
它的canWrite方法被父類AbstractHttpMessageConverter重寫了。
發現SUPPORTED_CLASSES中沒有Map類(本文demo返回的是Map類),因此不支持。
下面看Jaxb2RootElementHttpMessageConverter:
這個類直接重寫了canWrite方法。
需要有XmlRootElement注解。 很明顯,Map類當然沒有。
最終MappingJackson2HttpMessageConverter匹配,進行json轉換。(為何匹配,請讀者自行查看源碼)
我們分析了轉換器的轉換過程之后,下面就通過實例來驗證我們的結論吧。
首先,我們先把xml轉換器實現。
之前已經分析,默認的轉換器中是支持xml的。下面我們加上注解試試吧。
由于Map是jdk源碼中的部分,因此我們用Employee來做demo。
因此,Controller加上一個方法:
@RequestMapping("/xmlOrJsonSimple") @ResponseBody public Employee xmlOrJsonSimple() { return employeeService.getById(1); }
實體中加上@XmlRootElement注解
結果如下:
我們發現,解析成了xml。
這里為什么解析成xml,而不解析成json呢?
之前分析過,消息轉換器是根據class和mediaType決定的。
我們使用firebug看到:
我們發現Accept有xml,沒有json。因此解析成xml了。
我們再來驗證,同一地址,HTTP頭部不同Accept。看是否正確。
$.ajax({ url: "${request.contextPath}/employee/xmlOrJsonSimple", success: function(res) { console.log(res); }, headers: { "Accept": "application/xml" } });
$.ajax({ url: "${request.contextPath}/employee/xmlOrJsonSimple", success: function(res) { console.log(res); }, headers: { "Accept": "application/json" } });
驗證成功。
如果不想使用 mvc:annotation-driven/中默認的RequestMappingHandlerAdapter的話,我們可以在重新定義這個bean,spring會覆蓋掉默認的RequestMappingHandlerAdapter。
為何會覆蓋,請參考樓主的另外一篇博客: http://www.cnblogs.com/fangjian0423/p/spring-Ordered-interface.html
` `
或者如果只想換messageConverters的話。
<mvc:annotation-driven> <mvc:message-converters> <bean class="org.example.MyHttpMessageConverter"/> <bean class="org.example.MyOtherHttpMessageConverter"/> </mvc:message-converters> </mvc:annotation-driven>
如果還想用其他converters的話。
以上是spring-mvc jar包中的converters。
這里我們使用轉換xml的MarshallingHttpMessageConverter。
這個converter里面使用了marshaller進行轉換
我們這里使用XStreamMarshaller。
json沒有轉換器,返回406.
至于xml格式的問題,大家自行解決吧。 這里用的是XStream~。
使用這種方式,pom別忘記了加入xstream的依賴:
<dependency> <groupId>com.thoughtworks.xstream</groupId> xstream <version>1.4.7</version> </dependency>
寫了這么多,可能讀者覺得有點羅嗦。 畢竟這也是自己的一些心得,希望都能說出來與讀者共享。
剛接觸SpringMVC的時候,發現這種自動轉換機制很牛逼,但是一直沒有研究它的原理,目前,算是了了一個小小心愿吧,SpringMVC還有很多內容,以后自己研究其他內容的時候還會與大家一起共享的。
文章難免會出現一些錯誤,希望讀者們能指明出來。
http://my.oschina.net/HeliosFly/blog/205343
http://my.oschina.net/lichhao/blog/172562
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html
概述 在SpringMVC中,可以使用@ RequestBody和@ResponseBody兩個注解,分別完成請求報文到對象和對象到響應報文的轉換,底層這種靈活的消息轉換機制,就是Spring3.x中新引入的HttpMessageConverter即消息轉換器機制。
#Http請求的抽象 還是回到請求-響應,也就是解析請求體,然后返回響應報文這個最基本的Http請求過程中來。我們知道,在servlet標準中,可以用javax.servlet.ServletRequest接口中的以下方法:
public ServletInputStream getInputStream() throws IOException;
來得到一個ServletInputStream。這個ServletInputStream中,可以讀取到一個原始請求報文的所有內容。同樣的,在javax.servlet.ServletResponse接口中,可以用以下方法:
public ServletOutputStream getOutputStream() throws IOException;
來得到一個ServletOutputStream,這個ServletOutputSteam,繼承自java中的OutputStream,可以讓你輸出Http的響應報文內容。
讓我們嘗試著像SpringMVC的設計者一樣來思考一下。我們知道,Http請求和響應報文本質上都是一串字符串,當請求報文來到java世界,它會被封裝成為一個ServletInputStream的輸入流,供我們讀取報文。響應報文則是通過一個ServletOutputStream的輸出流,來輸出響應報文。
我們從流中,只能讀取到原始的字符串報文,同樣,我們往輸出流中,也只能寫原始的字符。而在java世界中,處理業務邏輯,都是以一個個有業務意義的對象為處理維度的,那么在報文到達SpringMVC和從SpringMVC出去,都存在一個字符串到java對象的阻抗問題。這一過程,不可能由開發者手工轉換。我們知道,在Struts2中,采用了OGNL來應對這個問題,而在SpringMVC中,它是HttpMessageConverter機制。我們先來看兩個接口。
#HttpInputMessage 這個類是SpringMVC內部對一次Http請求報文的抽象,在HttpMessageConverter的read()方法中,有一個HttpInputMessage的形參,它正是SpringMVC的消息轉換器所作用的受體“請求消息”的內部抽象,消息轉換器從“請求消息”中按照規則提取消息,轉換為方法形參中聲明的對象。
package org.springframework.http; import java.io.IOException; import java.io.InputStream; public interface HttpInputMessage extends HttpMessage { InputStream getBody() throws IOException; }
#HttpOutputMessage 這個類是SpringMVC內部對一次Http響應報文的抽象,在HttpMessageConverter的write()方法中,有一個HttpOutputMessage的形參,它正是SpringMVC的消息轉換器所作用的受體“響應消息”的內部抽象,消息轉換器將“響應消息”按照一定的規則寫到響應報文中。
package org.springframework.http; import java.io.IOException; import java.io.OutputStream; public interface HttpOutputMessage extends HttpMessage { OutputStream getBody() throws IOException; }
#HttpMessageConverter 對消息轉換器最高層次的接口抽象,描述了一個消息轉換器的一般特征,我們可以從這個接口中定義的方法,來領悟Spring3.x的設計者對這一機制的思考過程。
package org.springframework.http.converter; import java.io.IOException; import java.util.List; import org.springframework.http.HttpInputMessage; import org.springframework.http.HttpOutputMessage; import org.springframework.http.MediaType; public interface HttpMessageConverter<T> { boolean canRead(Class<?> clazz, MediaType mediaType); boolean canWrite(Class<?> clazz, MediaType mediaType); List<MediaType> getSupportedMediaTypes(); T read(Class<? extends T> clazz, HttpInputMessage inputMessage) throws IOException, HttpMessageNotReadableException; void write(T t, MediaType contentType, HttpOutputMessage outputMessage) throws IOException, HttpMessageNotWritableException; }
HttpMessageConverter接口的定義出現了成對的canRead(),read()和canWrite(),write()方法,MediaType是對請求的Media Type屬性的封裝。舉個例子,當我們聲明了下面這個處理方法。
@RequestMapping(value="/string", method=RequestMethod.POST) public @ResponseBody String readString(@RequestBody String string) { return "Read string '" + string + "'"; }
在SpringMVC進入readString方法前,會根據@RequestBody注解選擇適當的HttpMessageConverter實現類來將請求參數解析到string變量中,具體來說是使用了StringHttpMessageConverter類,它的canRead()方法返回true,然后它的read()方法會從請求中讀出請求參數,綁定到readString()方法的string變量中。
當SpringMVC執行readString方法后,由于返回值標識了@ResponseBody,SpringMVC將使用StringHttpMessageConverter的write()方法,將結果作為String值寫入響應報文,當然,此時canWrite()方法返回true。
我們可以用下面的圖,簡單描述一下這個過程。
#RequestResponseBodyMethodProcessor 將上述過程集中描述的一個類是org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor,這個類同時實現了HandlerMethodArgumentResolver和HandlerMethodReturnValueHandler兩個接口。前者是將請求報文綁定到處理方法形參的策略接口,后者則是對處理方法返回值進行處理的策略接口。兩個接口的源碼如下:
package org.springframework.web.method.support; import org.springframework.core.MethodParameter; import org.springframework.web.bind.WebDataBinder; import org.springframework.web.bind.support.WebDataBinderFactory; import org.springframework.web.context.request.NativeWebRequest; public interface HandlerMethodArgumentResolver { boolean supportsParameter(MethodParameter parameter); Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception; } package org.springframework.web.method.support; import org.springframework.core.MethodParameter; import org.springframework.web.context.request.NativeWebRequest; public interface HandlerMethodReturnValueHandler { boolean supportsReturnType(MethodParameter returnType); void handleReturnValue(Object returnValue, MethodParameter returnType, ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception; }
RequestResponseBodyMethodProcessor這個類,同時充當了方法參數解析和返回值處理兩種角色。我們從它的源碼中,可以找到上面兩個接口的方法實現。
對HandlerMethodArgumentResolver接口的實現:
public boolean supportsParameter(MethodParameter parameter) { return parameter.hasParameterAnnotation(RequestBody.class); } public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception { Object argument = readWithMessageConverters(webRequest, parameter, parameter.getGenericParameterType()); String name = Conventions.getVariableNameForParameter(parameter); WebDataBinder binder = binderFactory.createBinder(webRequest, argument, name); if (argument != null) { validate(binder, parameter); } mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult()); return argument; }
對HandlerMethodReturnValueHandler接口的實現
public boolean supportsReturnType(MethodParameter returnType) { return returnType.getMethodAnnotation(ResponseBody.class) != null; } public void handleReturnValue(Object returnValue, MethodParameter returnType, ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws IOException, HttpMediaTypeNotAcceptableException { mavContainer.setRequestHandled(true); if (returnValue != null) { writeWithMessageConverters(returnValue, returnType, webRequest); } }
看完上面的代碼,整個HttpMessageConverter消息轉換的脈絡已經非常清晰。因為兩個接口的實現,分別是以是否有@RequestBody和@ResponseBody為條件,然后分別調用HttpMessageConverter來進行消息的讀寫。
如果你想問,怎么樣跟蹤到RequestResponseBodyMethodProcessor中,請你按照前面幾篇博文的思路,然后到這里 spring-mvc-showcase下載源碼回來,對其中HttpMessageConverter相關的例子進行debug,只要你肯下功夫,相信你一定會有屬于自己的收獲的。
#思考 張小龍在談微信的本質時候說:“微信只是個平臺,消息在其中流轉”。在我們對SpringMVC源碼分析的過程中,我們可以從HttpMessageConverter機制中領悟到類似的道理。在SpringMVC的設計者眼中,一次請求報文和一次響應報文,分別被抽象為一個請求消息HttpInputMessage和一個響應消息HttpOutputMessage。
處理請求時,由合適的消息轉換器將請求報文綁定為方法中的形參對象,在這里,同一個對象就有可能出現多種不同的消息形式,比如json和xml。同樣,當響應請求時,方法的返回值也同樣可能被返回為不同的消息形式,比如json和xml。
在SpringMVC中,針對不同的消息形式,我們有不同的HttpMessageConverter實現類來處理各種消息形式。但是,只要這些消息所蘊含的“有效信息”是一致的,那么各種不同的消息轉換器,都會生成同樣的轉換結果。至于各種消息間解析細節的不同,就被屏蔽在不同的HttpMessageConverter實現類中了。
以上是“SpringMVC中如何使用消息轉換器HttpMessageConverter與@ResponseBody注解”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。