SpringMVC處理靜態文件源碼分析

jopen 9年前發布 | 31K 次閱讀 SpringMVC Spring MVC Web框架

SpringMVC處理靜態資源，主要是兩個標簽，mvc:resources和 mvc:default-servlet-handler。在詳細說明他們的原理之前，需要先簡單說明下SpringMVC中請求處理機制：HandlerMapping和HandlerAdapter。

1 HandlerMapping和HandlerAdapter的來由

用過python Django框架的都知道Django對于訪問方式的配置就是，一個url路徑和一個函數配對，你訪問這個url，就會直接調用這個函數，簡單明了

然而對于SpringMVC框架來說，由于java的面向對象,就要找到對應的類以及對應的方法，所以就需要分成2步走

第一步先找到url對應的處理類，叫handler,這里就用到HandlerMapping來尋找
第二步找到了對應的handler之后，我們該調用這個handler的哪個方法呢？這就需要HandlerAdapter來決定

2 常用的HandlerMapping和HandlerAdapter簡單介紹

2.1 HandlerMapping接口設計和實現

public interface HandlerMapping {
    HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;
}

根據request請求，找到對應的HandlerExecutionChain，HandlerExecutionChain是handler和攔截器的結合。如下：

public class HandlerExecutionChain {
    private final Object handler;
    private List<HandlerInterceptor> interceptorList;
}

即針對某個請求，會有對應的handler和攔截器來處理。HandlerMapping僅僅是找到對應的handler和攔截器罷了，它并不限制 handler的類型，任何一個存在于Spring的IOC容器中的bean都可以成為handler，所以這個handler是Object。

下面來看下常見的幾個HandlerMapping實現：

BeanNameUrlHandlerMapping ：對url直接配置一個bean作為這個url的handler。如在xml中如下配置
```
<bean name="/index" class="com.lg.mvc.HomeAction"></bean>
```
當我們訪問 http://localhost:8080/index 時，就直接找到這個bean作為handler。

SimpleUrlHandlerMapping ：上述只能配置一個url對應的bean，SimpleUrlHandlerMapping就可以配置多個，功能上更強大，它內部有一個Map urlMap，存放著各個url對應的handler，如下

<bean id="handler1" class="XXXX"/>
<bean id="handler2" class="XXXXX"/>
<bean id="handlerMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
     <property name="urlMap">
         <map>
            <entry key="/user/login.do" value-ref="handler1"/>
            <entry key="/admin/admin.do" value-ref="handler2"/>
         </map>
     </property>
</bean>

2.2 HandlerAdapter接口設計和實現

public interface HandlerAdapter {
    boolean supports(Object handler);
    ModelAndView handle(HttpServletRequest request, HttpServletResponse response,
             Object handler) throws Exception;
}

根據HandlerMapping找到了handler之后，我們該調用handler的哪個方法呢？handler又有哪些方法呢？這里就需要采用適配器的模式，對不同的handler進行不同的處理。因此HandlerAdapter的supports方法首先判斷這個handler是否是我能支持的，如果能支持，那我就按照我的處理模式來處理，即調用上述的handle方法。

下面來看下常見的幾個HandlerAdapter的實現：

SimpleServletHandlerAdapter ：它支持的handler必須是Servlet，這樣的話該handler就必然有service(request, response)方法，所以就會調用handler的service(request, response)方法來處理請求，源碼如下

public class SimpleServletHandlerAdapter implements HandlerAdapter {
    @Override
    public boolean supports(Object handler) {
        return (handler instanceof Servlet);
    }
    @Override
    public ModelAndView handle(HttpServletRequest request, HttpServletResponse response
            , Object handler)throws Exception {
        ((Servlet) handler).service(request, response);
        return null;
    }
}

SimpleControllerHandlerAdapter ：它支持的handler必須是Controller，Controller接口定義了一個ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response)方法，所以我們知道該handler必然有一個handleRequest方法，就調用它來處理請求，源碼如下

public class SimpleControllerHandlerAdapter implements HandlerAdapter {
    @Override
    public boolean supports(Object handler) {
        return (handler instanceof Controller);
    }
    @Override
    public ModelAndView handle(HttpServletRequest request, HttpServletResponse response
            , Object handler)throws Exception {
        return ((Controller) handler).handleRequest(request, response);
    }
}

HttpRequestHandlerAdapter ：它支持的handler必須是HttpRequestHandler，HttpRequestHandler接口定義了一個void handleRequest(HttpServletRequest request, HttpServletResponse response)方法，所以就知道該調用這個handler的handleRequest方法，源碼如下：

public class HttpRequestHandlerAdapter implements HandlerAdapter {
    @Override
    public boolean supports(Object handler) {
        return (handler instanceof HttpRequestHandler);
    }
    @Override
    public ModelAndView handle(HttpServletRequest request, HttpServletResponse response
            , Object handler)throws Exception {
        ((HttpRequestHandler) handler).handleRequest(request, response);
        return null;
    }
}

以上的幾個HandlerMapping和HandlerAdapter屬于SpringMVC最初的設計思路。即HandlerMapping和 HandlerAdapter毫無關系，HandlerMapping只負責找到對應的handler，HandlerAdapter負責找到 handler的哪個方法。然而隨著注解的興起，即@RequestMapping注解直接標注請求對應某個類的某個方法，使得后來的 HandlerMapping和HandlerAdapter即 DefaultAnnotationHandlerMapping、AnnotationMethodHandlerAdapter 、RequestMappingHandlerMapping 、RequestMappingHandlerAdapter（前兩者已被后兩者取代）不再像之前的思路那樣，開始爭奪權力了，RequestMappingHandlerMapping 在尋找對應的handler時，不僅要匹配到對應的handler，還要找到對應的方法。它們具體詳細的內容，可以參考我的之前的博客 mvc:annotation-driven以及@Controller和@RequestMapping的那些事

接下來就輪到重點了（上面的鋪墊夠長的了，哈哈）

3 mvc:resources源碼分析

來看下一般的mvc:resources的使用，如下：

<mvc:resources location="/WEB-INF/views/css/**" mapping="/css/**"/>

然后來看源碼。首先要再次聲明下，所有在xml中配置的標簽，都會有對應的BeanDefinitionParser的實現類來進行處理，對于 mvc:resources標簽，對應的實現類是ResourcesBeanDefinitionParser，查看其中的源碼（這里不再列出，自行去查看），可以知道

注冊了一個SimpleUrlHandlerMapping（上文已提到）。它是擁有一個Map urlMap的，它把mvc:resources標簽中的mapping屬性作為key,把ResourceHttpRequestHandler作為 handler。即/css/**類似的url請求，會由這個SimpleUrlHandlerMapping匹配到 ResourceHttpRequestHandler上。

再看下，到底調用ResourceHttpRequestHandler的哪個方法來處理請求呢？

ResourceHttpRequestHandler實現了HttpRequestHandler，即是上文提到的 HttpRequestHandlerAdapter支持的handler類型，所以就會調用ResourceHttpRequestHandler的 void handleRequest(HttpServletRequest request, HttpServletResponse response)方法

其實很容易就明白了，ResourceHttpRequestHandler會根據mvc:resources標簽中的location屬性作為目錄，去尋找對應的資源，然后返回資源的內容。這里就不再詳細說明了，可以自行查看ResourceHttpRequestHandler的所實現的 handleRequest方法。

4 mvc:default-servlet-handler 源碼分析

同理，mvc:default-servlet-handler標簽對應的BeanDefinitionParser的實現類是DefaultServletHandlerBeanDefinitionParser。

這里注冊了SimpleUrlHandlerMapping，它的Map urlMap中存放了一個 key為/* ，對應的handler為DefaultServletHttpRequestHandler。即請求路徑匹配 / * 的時候，這個SimpleUrlHandlerMapping會交給DefaultServletHttpRequestHandler來處理。這種情況一般是其他HandlerMapping無法匹配處理，最后才無奈交給DefaultServletHttpRequestHandler。

來看下DefaultServletHttpRequestHandler是怎么處理的：

它同樣實現了HttpRequestHandler接口，擁有void handleRequest(HttpServletRequest request, HttpServletResponse response)方法，如下：

@Override
public void handleRequest(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {

    RequestDispatcher rd = this.servletContext.getNamedDispatcher(this.defaultServletName);
    if (rd == null) {
        throw new IllegalStateException("A RequestDispatcher could not be located for the default servlet '" +
                this.defaultServletName +"'");
    }
    rd.forward(request, response);
}

我們可以看到，這里其實就是轉發給了web容器自身的servlet。這個servlet名稱可以在mvc:default-servlet-handler標簽中進行配置，如果沒有配置，采用默認的配置，如下：

/** Default Servlet name used by Tomcat, Jetty, JBoss, and GlassFish */
private static final String COMMON_DEFAULT_SERVLET_NAME = "default";

/** Default Servlet name used by Google App Engine */
private static final String GAE_DEFAULT_SERVLET_NAME = "_ah_default";

/** Default Servlet name used by Resin */
private static final String RESIN_DEFAULT_SERVLET_NAME = "resin-file";

/** Default Servlet name used by WebLogic */
private static final String WEBLOGIC_DEFAULT_SERVLET_NAME = "FileServlet";

/** Default Servlet name used by WebSphere */
private static final String WEBSPHERE_DEFAULT_SERVLET_NAME = "SimpleFileServlet";

即tomcat、Jetty等，在容器啟動的時候，自身就默認注冊了一個name叫default的servlet，可以從我的上一篇文章進行了解tomcat的url-pattern的源碼分析。DefaultServletHttpRequestHandler就是轉發給這些servlet。

其實這個時候，請求先經過tomcat的servlet的url-pattern的匹配，進入到了SpringMVC,然后經過SpringMVC 的HandlerMapping的一系列匹配，沒有對應的handler匹配，導致又再次轉發給tomcat等默認的servlet上了，繞了很大的彎，所以要盡量避免這樣的操作。

5 結合tomcat的url-pattern來綜合案例

這里舉一個案例進行分析，在tomcat發布的根目錄中，有一個a.html和a.jsp文件，以及一個SpringMVC項目，如下：

SpringMVC處理靜態文件源碼分析

其中SpringMVC項目配置了mvc:default-servlet-handler標簽，接下來以SpringMVC的DispatcherServlet的兩種配置進行說明，分別是

/ 和 /* 兩種方式

結果分別是：

DispatcherServlet配置為 / 的時候，a.html和a.jsp都可以正常訪問到，如下
DispatcherServlet配置為 /* 的時候,a.html可以正常訪問到，a.jsp就不行了，如下

分析如下：

我們知道 /* 的優先級大于 .jsp的優先級，.jsp的優先級大于 / （可以由我的上一篇文章了解到tomcat的url-pattern的源碼分析），在這個前提下

訪問a.html時：

當DispatcherServlet配置為 / 的時候，tomcat仍會選擇SpringMVC的DispatcherServlet來處理a.html-》它也處理不了，交給默認配置的 mvc:default-servlet-handler來處理-》轉發到tomcat默認的servlet的，即DefaultServlet來處理 -》DefaultServlet去尋找有沒有該文件，找到了，返回文件內容
當DispatcherServlet配置為 /* 的時候，tomcat仍然是選擇SpringMVC的DispatcherServlet來處理a.html，同上面是一樣的過程

訪問a.jsp時：

當DispatcherServlet配置為 / 的時候，tomcat會優先選擇自己已經默認注冊的JspServlet來處理-》JspServlet翻譯文件內容，返回
當DispatcherServlet配置為 /* 的時候，tomcat會選擇SpringMVC的DispatcherServlet來處理a.jsp-》發現SpringMVC找不到匹配的 handler，交給配置的mvc:default-servlet-handler來處理-》轉發到tomcat默認的servlet的，即 DefaultServlet來處理-》DefaultServlet僅僅將a.jsp的源碼內容進行返回

本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1426668721164.html

SpringMVC Spring MVC Web框架

SpringMVC處理靜態文件源碼分析

1 HandlerMapping和HandlerAdapter的來由

2 常用的HandlerMapping和HandlerAdapter簡單介紹

2.1 HandlerMapping接口設計和實現

2.2 HandlerAdapter接口設計和實現

3 mvc:resources源碼分析

4 mvc:default-servlet-handler 源碼分析

5 結合tomcat的url-pattern來綜合案例

相關經驗

相關資訊

相關文檔

目錄