解读Tomcat（五）请求处理Part_3

annegu

浏览: 98740 次
性别:
来自: 杭州

最近访客更多访客>>

h521999

raoyutao

xiongc

frk

博主相关

博客

微博

相册

留言

关于我

文章分类

全部博客 (16)

社区版块

存档分类

Tomcat Servlet 设计模式 Apache 数据结构

/**
*作者:annegu
*日期:2009-06-24
*/

现在我们从connector.getContainer().getPipeline().getFirst().invoke(request, response)开始进入容器...

前面说到容器的时候，anne一直都只有说三个容器，engine, host, context。其实在context之下，还有一个容器，叫做wrapper，每个wapper包含了一个servlet，因此前文没有接触到servlet的时候，就暂时省略了。好了，现在我们知道了有这四个级别的容器。这四个容器素由上至下逐渐细分，形成树状结构，构成了tomcat容器结构的主体，它们都位于org.apache.catalina包内。

之前在第二部分tomcat的启动的时候，我们就看到了pipeline，pipeline是一种上级容器和下级容器进行沟通的管道，当上级容器种的request和response要被传递到下一个容器中去时，就必须通过这个管道，而value就像管道中的一个个阀门一样，给传递的request和response把把关，只有过了所有的阀门，才能被正确的传递到下一级容器中去。Tomcat中的pipeline/valve是标准的责任链模式，每个级别的容器中pipeline下都有配置value，每种类型的value专门负责做一项工作，比如验证Request的有效性、写日志等等。请求先到达第一个value，value会对其做一些工作，当工作做完后，将请求传递给下一个value。每个pipeline的最后都会有一个BasicValue(比如Engine的StandardEngineValue、Host的StanadrdHostValue)，它负责寻找下一级容器的pipeline，并且将请求传递给下一级容器的pipeline中的value，这样一直传递下去直到真正的servlet。

在tomcat中，这个责任链真是最最标准，最最基础的责任链了，我们来看一下StandardPipeline中是怎样为pipeline添加value的：

    public void addValve(Valve valve) {    
        if (valve instanceof Contained)
            ((Contained) valve).setContainer(this.container);

        ...// Start the new component if necessary

        // Add this Valve to the set associated with this Pipeline
①      if (first == null) {
        	first = valve;
        	valve.setNext(basic);
        } else {
            Valve current = first;
            while (current != null) {
				if (current.getNext() == basic) {
					current.setNext(valve);
					valve.setNext(basic);
					break;
				}
				current = current.getNext();
			}
        }
}

First（代码①处）记录了这个pipeline关联着的第一个value，basic则是pipeline关联的最后一个value，执行完basic，就进入到下一级的容器中去了。
从上面的代码，我们可以看到，pipeline用了一种最基本的方法来维持这个value的链条，每个value都保持了一个下个value的引用。于是，我们就看到connector.getContainer().getPipeline().getFirst()就得到了engine中的第一个value。为什么呢？因为connector.getContainer()得到的是connector父节点（也就是service）中的engine容器，进而getPipeline()得到engine的pipeline，getFirst()得到engine的pipeline中的第一个value。

好了，下面我们来看看具体进入到了value，都做了些什么，我们来看一个AccessLogValue，很明显，是一个用来写日志的value。

    public void invoke(Request request, Response response) throws IOException, ServletException {
        if (started && getEnabled()) {                
            long t1 = System.currentTimeMillis();
    
  ②        getNext().invoke(request, response);
    
            long t2 = System.currentTimeMillis();
            long time = t2 - t1;    
            StringBuffer result = new StringBuffer();
  			...    //add log info into result
            log(result.toString());
        } else
            getNext().invoke(request, response);       
    }

OK，很明显，value是通过getNext()方法来得到下一个责任链上的value的（代码②处）。那么当这个责任链到头了，进入到了最后一个value的话是怎么处理的呢？前面说了，每个容器的pipeline的责任链的末端都会有一个特殊的value，Engine的StandardEngineValue、Host的StanadrdHostValue，Context的StanadrdContextValue，Wrapper的StanadrdWrapperValue，这些叫做basicValue，对于容器来说，这些basicValue是一定会有的。我们就看一个StandardEngineValue：

    public final void invoke(Request request, Response response)
        throws IOException, ServletException {
        // Select the Host to be used for this Request
        Host host = request.getHost();
        if (host == null) {
            response.sendError
                (HttpServletResponse.SC_BAD_REQUEST,
                 sm.getString("standardEngine.noHost", 
                              request.getServerName()));
            return;
        }

        // Ask this Host to process this request
③      host.getPipeline().getFirst().invoke(request, response);
    }

我们可以看到在basicValue中得到了下一级容器，并且调用了下级容器的pipeline中的first value（代码③处）。对于StanadrdHostValue，StanadrdContextValue和StanadrdWrapperValue来说，也都是类似的。BasicValue放在org.apache.catalina.core下，而其他的value都放在org.apache.catalina.value下面。

Ok，大家继续脑补一下，现在已经进入到StanadrdWrapperValue了。那根据我们对tomcat的了解下面应该做什么了呢？对了，接下来我们就要穿越过层层filter，进入servlet了。
我们看一下StanadrdWrapperValuede的invoke方法，为了看起来方便一点，anne就大刀阔斧的只截取了一点点我们需要关注的内容。

    public final void invoke(Request request, Response response)
        throws IOException, ServletException {
         ...
   ④	servlet = wrapper.allocate();

        // 下面开始创建filter链啦
   ⑤   ApplicationFilterFactory factory =
            ApplicationFilterFactory.getInstance();
        ApplicationFilterChain filterChain =
            factory.createFilterChain(request, wrapper, servlet);
        ...

        // 调用filter链
        filterChain.doFilter(request.getRequest(),response.getResponse());

        if (servlet != null) {
           wrapper.deallocate(servlet);
        }
     }

因为一个wrapper是对应与一个servlet的，所以wrapper.allocate()就是得到它负责封装的那个servlet（代码④处）。
下面在代码⑤处，我们就要来创建filter chain了，anne照样把createFilterChain中的方法稍微提取了一下：

  public ApplicationFilterChain createFilterChain
        (ServletRequest request, Wrapper wrapper, Servlet servlet) {
    ApplicationFilterChain filterChain = new ApplicationFilterChain();
    filterChain.setServlet(servlet); 

    // 得到context的filter mapping
    StandardContext context = (StandardContext) wrapper.getParent();
    FilterMap filterMaps[] = context.findFilterMaps();

    // 遍历filterMaps，如果有符合这个servlet的filter就把它加到filter chain中
    for (int i = 0; i < filterMaps.length; i++) {
        if (!matchDispatcher(filterMaps[i] ,dispatcher)) {
          continue;
        }
        if (!matchFiltersURL(filterMaps[i], requestPath))
            continue;

        ApplicationFilterConfig filterConfig = (ApplicationFilterConfig)
                context.findFilterConfig(filterMaps[i].getFilterName());
        if (filterConfig == null) {
            continue;
        }
        filterChain.addFilter(filterConfig);
     }
    return (filterChain);
}

我们都知道filter chain也是采用的责任链模式，前面我们说到pipeline中的value也是采用的责任链模式，每个value都持有了下一个value的引用。我们可以看看ahuaxuan的《请问责任链真的是一种设计模式吗》这篇文章(http://ahuaxuan.iteye.com/blog/105825)，这里面谈到了三种责任链的实现方式，filter chain就是这第三种潇洒版责任链。
前面pipeline的value链是通过引用的方式来形成一条隐形的链条，而这里，filterChain是真是存在的。我们只需要把这个链条上面的一个一个关节通过filterChain.addFilter()装上即可。这个filterChain中的每个关节都是一个FilterConfig对象，这个对象中包含了filter，context，initParameter等等。

链条组装完毕！
启动filterChain.doFilter()！
doFilter方法主要调用了internalDoFilter()。

    public void doFilter(ServletRequest request, ServletResponse response)
        throws IOException, ServletException {
        ...
        internalDoFilter(request,response);
    }

    private void internalDoFilter(ServletRequest request, 
                                  ServletResponse response)
        throws IOException, ServletException { 
  ⑥    if (pos < n) {
            ApplicationFilterConfig filterConfig = filters[pos++];
            Filter filter = null; 
            filter = filterConfig.getFilter();
...
            filter.doFilter(request, response, this);
		}

   ⑦       if ((request instanceof HttpServletRequest) &&
                (response instanceof HttpServletResponse)) {
                    servlet.service((HttpServletRequest) request,
                                    (HttpServletResponse) response);
                }
            } else {
                servlet.service(request, response);
            }
    }

代码⑥处的pos是filter chain上的一个标识位，表示现在执行的是哪一个filter。然后调用了filter的doFilter方法。我们来看一个例子，一个用来记录执行时间的filter。

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
	throws IOException, ServletException {
	  if (attribute != null)
	      request.setAttribute(attribute, this);

	  long startTime = System.currentTimeMillis();
   ⑧     chain.doFilter(request, response);
	  long stopTime = System.currentTimeMillis();
	  filterConfig.getServletContext().log
	      (this.toString() + ": " + (stopTime - startTime) +
	       " milliseconds");
    }

首先把当前正在执行的这个filter作为一个attribute放到request中去，接下来我们可以看到在两个time之间，调用了chain.doFilter()（代码⑧处），Chain就是filter chain。这下又要回到internalDoFilter，pos又加了1，就变成执行filterChain的下一个filter了。
如果这个filter chain已经到头了（pos=n），那就进入代码⑦处，就表示request和response已经突破filter的重重阻拦，可以进入servlet了。因此，我们就可以调用wrapper内的servlet的service()方法了。自此进入servlet。这下我们知道了filter原来是这样执行的，它是一层包着一层，一直不断的向内层进发，当进入到最内层，就是servlet了。

好了，我们现在终于进入servlet的service方法了。

    protected void service(HttpServletRequest req, HttpServletResponse resp)
        throws ServletException, IOException {

        String method = req.getMethod();

        if (method.equals(METHOD_GET)) {
...
            doGet(req, resp);
        } else if (method.equals(METHOD_HEAD)) {
            doHead(req, resp);
        } else if (method.equals(METHOD_POST)) {
            doPost(req, resp);            
        } else if (method.equals(METHOD_PUT)) {
            doPut(req, resp);                    
        } else if (method.equals(METHOD_DELETE)) {
            doDelete(req, resp);            
        } else if (method.equals(METHOD_OPTIONS)) {
            doOptions(req,resp);            
        } else if (method.equals(METHOD_TRACE)) {
            doTrace(req,resp);            
        } else {
            ...// NO servlet supports
        }
    }

Service方法里面其实很简单，就是根据不同的请求，调用不同的do***()方法。Http的请求类型一共有如上七种。
一个HttpServlet的子类必须至少覆写以下方法中的一个。
1) doGet()方法，适用于HTTP GET请求。自动支持一个HTTP HEAD请求。当覆写doGet()时，首先读取请求数据，写入响应的head，然后获得响应的writer或输出流对象，最后写入响应数据。
2) doPost()方法，适用于HTTP POST请求。覆写该方法与doGet()类似。
3) doPut()方法，适用于HTTP PUT请求。PUT操作允许客户好像使用FTP一样把文件放置到服务器。
4) doDelete()方法，适用于HTTP DELETE请求。DELETE操作允许客户从服务器中删除一个文档或网页。
5) init()和destroy()方法，管理Servlet生命周期中的资源。
6) getServletInfo()方法，提供Servlet本身的信息。

另外还有不需要覆写的方法：
7) doHead()方法，适用于HTTP HEAD请求。当客户端只需要知道响应头，比如Content-Type或者Content-Length，客户端只需要发送一个HEAD请求。HTTP HEAD会准确地计算输出的字节数来设定Content-Length。如果覆写该方法，可以避免计算响应的BODY，而只需设置响应头以改善性能。
8) doOptions()方法，适用于OPTIONS请求。OPTIONS操作决定服务器支持哪种HTTP方法，并返回一个适当的头信息。例如，如果一个servlet覆写了doGet()方法，doOptions()方法将会返回如下头信息：Allow: GET, HEAD, TRACE, OPTIONS。
9) doTrace()方法，适用于TRACE请求。该方法用于程序调试，无需被覆写。

尽管说有这么多do***()方法，可是我们常用的就只有doGet()和doPost()。

Tomcat6讲到这里就大概差不多了，它的组成，启动，消息处理都过了一遍。不过消息处理我只写了nio的处理方式，下篇看看要不写下传统的bio方式。

That’s all!