SpringMVC处理静态文件源码分析

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项目配置了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的源码内容进行返回
时间: 2024-10-10 15:25:49

SpringMVC处理静态文件源码分析的相关文章

Hhadoop-2.7.0中HDFS写文件源码分析(二):客户端实现(1)

一.综述       HDFS写文件是整个Hadoop中最为复杂的流程之一,它涉及到HDFS中NameNode.DataNode.DFSClient等众多角色的分工与合作.       首先上一段代码,客户端是如何写文件的: Configuration conf = new Configuration(); FileSystem fs = FileSystem.get(conf); Path file = new Path("demo.txt"); FSDataOutputStream

Hhadoop-2.7.0中HDFS写文件源码分析(二):客户端实现之DFSPacket

一.简介       HDFS在数据传输过程中,针对数据块Block,不是整个block进行传输的,而是将block切分成一个个的数据包进行传输.而DFSPacket就是HDFS数据传输过程中对数据包的抽象. 二.实现       HDFS客户端在往DataNodes节点写数据时,会以数据包packet的形式写入,且每个数据包包含一个包头,n个连续的校验和数据块checksum chunks和n个连续的实际数据块 actual data chunks,每个校验和数据块对应一个实际数据块,被用来做

SpringMVC文件上传源码分析前言

该如何研究SpringMVC的文件上传的源码呢? 研究源码并不是仅仅知道程序是怎样运行的,而应该从宏观的角度.不同的立场去看待问题.以SpringMVC文件上传的源码为例(麻雀虽小,五脏俱全),我们应该从下面几个方面去分析和研究: 1 文件上传的基本规则:以什么样的格式来传输数据? get or post ? 与其他字段如何共存 ? 多文件上传? 2 站在apache fileupload的角度 apache fileupload目的是想写一个通用的解析文件上传的jar包,可以供所有的java

详解SpringMVC中Controller的方法中参数的工作原理[附带源码分析] good

目录 前言 现象 源码分析 HandlerMethodArgumentResolver与HandlerMethodReturnValueHandler接口介绍 HandlerMethodArgumentResolver与HandlerMethodReturnValueHandler接口的具体应用 常用HandlerMethodArgumentResolver介绍 常用HandlerMethodReturnValueHandler介绍 本文开头现象解释以及解决方案 编写自定义的HandlerMet

Tomcat源码分析——server.xml文件的解析

前言 在<Tomcat源码分析--server.xml文件的加载>一文中我们介绍了server.xml的加载,本文基于Tomcat7.0的Java源码,接着对server.xml文件是如何解析的进行分析. 概要 规则 Tomcat将server.xml文件中的所有元素上的属性都抽象为Rule,以Server元素为例,在内存中对应Server实例,Server实例的属性值就来自于Server元素的属性值.通过对规则(Rule)的应用,最终改变Server实例的属性值. Rule是一个抽象类,其中

Tomcat源码分析——server.xml文件的加载

前言 作为Java程序员,对于tomcat的server.xml想必都不陌生.本文基于Tomcat7.0的Java源码,对server.xml文件是如何加载的进行分析. 源码分析 Bootstrap的load方法用于加载tomcat的server.xml,实际是通过反射调用Catalina的load方法,代码如下: /** * Load daemon. */ private void load(String[] arguments) throws Exception { // Call the

tomcat的url-pattern的源码分析

1 静态文件的处理前言分析 最近想把SpringMVC对于静态资源的处理策略弄清楚,如它和普通的请求有什么区别吗? 有人可能就要说了,现在有些静态资源都不是交给这些框架来处理,而是直接交给容器来处理,这样更加高效.我想说的是,虽然是这样,处理静态资源也是MVC框架应该提供的功能,而不是依靠外界. 这里以tomcat容器中的SpringMVC项目为例.整个静态资源的访问,效果图如下: 可以分成如下2个大的过程 tomcat根据url-pattern选择servlet的过程 SpringMVC对静态

Android 源码分析,FreeMind 是一件超级利器

Android 源码分析,FreeMind 是一件超级利器 思维导图软件 XMind 与 FreeMind 的对比 作者: 善用佳软 日期: 2012-04-17 分类: 1 文本办公, 1.5 思维导图 标签: mindmap 思维导图类软件中,最有影响力的开源免费软件是 FreeMind 和 XMind.FreeMind历史悠久,当属经典:XMind作为后起之秀,大有赶超之势.同作为免费.开源的思维导图解决方案,应如何选择/结合两款软件?本文试做分析,以供用户/开发者参考. 本文的分析基于W

sigslot库源码分析

最近一直在忙毕设的事情,博客都快被遗忘了.最近正好在研究sigslot库,索性晚上写点源码分析的水文充充数. 言归正传,sigslot是一个用标准C++语法实现的信号与槽机制的函数库,类型和线程安全.提到信号与槽机制,恐怕最容易想到的就是大名鼎鼎的Qt所支持的对象之间通信的模式吧.不过这里的信号与槽虽然在概念上等价与Qt所实现的信号与槽,但是采用的仅仅是标准C++语法,不像Qt采用了扩展C++语言的方式(Qt需要使用moc工具对代码预处理之后,才能由标准的C++编译器进行编译). 众所周知,C+