站内搜索: 请输入搜索关键词

当前页面: 开发资料首页 → Spring 专题 → 根据petclinic项目手把手教你剖析SpringFramework源代码---mvc篇

根据petclinic项目手把手教你剖析SpringFramework源代码---mvc篇

摘要: 根据petclinic项目手把手教你剖析SpringFramework源代码---mvc篇 根据petclinic项目手把手教你剖析SpringFramework源代码---mvc篇 关键词:...
根据petclinic项目手把手教你剖析SpringFramework源代码---mvc篇


↑返回目录
前一篇: 根据petclinic项目手把手教你剖析SpringFramework源代码---准备篇
后一篇: Spring Framework标记库初学者指南

              根据petclinic项目手把手教你剖析SpringFramework源代码---mvc篇

关键词:SpringFramework,mvc


二.SpringFramework的mvc

既然petclinic是个web application,我们当然从web.xml文件入手了。首先当然welcome-file-list条目了，该条目指出index.jsp是网站的入口。index.jsp写得很简单，只有3行。如下所示:
<%@ include file="/WEB-INF/jsp/includes.jsp" %>
<%-- Redirected because we can't set the welcome page to a virtual URL. --%>
<c:redirect url="/welcome.htm"/>

第一行是一条include指令，包括了一个includes.jsp,该jsp文件里面有web application用到的标记库的全部声明语句。因此第三条语句c:redirect就用的很自然了，从该语句可以看到，web container把请求重定向为/welcome.htm请求了。再查看一下web.xml,有这么一段:
<servlet-mapping>
  <servlet-name>petclinic</servlet-name>
  <url-pattern>*.htm</url-pattern>
</servlet-mapping>
由此，我们可知，web container把匹配*.htm的请求都交给petclinic servlet也就是org.springframework.web.servlet.DispatcherServlet来处理了。DispatcherServlet是研究SpringFramework mvc的关键类，在你的spring 工程中打开该类的源代码吧。

在你spring工程中你可以看到,DispatcherServlet的父类是FrameworkServlet,FrameworkServlet的父类HttpServletBean,而HttpServletBean的父类是HttpServlet,因此DispatcherServlet本质上是个HttpServlet.在web.xml中的<load-on-startup>2</load-on-startup>表明,jsp container 在启动的时候就会生成2个DispatcherServlet,自然会执行其init()方法了。从DispatcherServlet的源代码来看，他并没有直接覆盖父类的init(),我们再来看看FrameworkServlet的init(),呵呵，FrameworkServlet也没有，一路追溯上去，终于在HttpServletBean类中找到了init(),该方法中调用initServletBean();再看FrameworkServlet的initServletBean(),里面关键的有2句:
1.this.webApplicationContext = initWebApplicationContext();
2.initFrameworkServlet();
我们先来看第一句 initWebApplicationContext();在开始研究这个方法之前，我们得了解一下Spring的WebApplicationContext是个什么东西，从spring-reference.pdf的第九章的得知，每一个DispatcherServlet都有它的WebApplicationContext，每一个WebApplicationContext都是
一个applicationContext,自然也是一个BeanFactory了，而且，每一个WebApplicationContext有一个parent WebApplicationContext,这个parent是整个web application的Context，自然也是个BeanFactory，这个parent的内容默认是从/web-inf/applicationContext.xml文件装载,而DispatcherServlet自己的WebApplicationContext则是从一个叫xxxx-servlet.xml的文件装载的。xxxx就是在web.xml为DispatcherServlet定义的servlet-name.明白了这层关系，我们再来看initWebApplicationContext(),它所做的无非就是生成DispatcherServlet的WebApplicationContext,同时设置好它的相关属性。我们先来看看它的parent属性是如何设置的。然后再看他自己的WebApplicationContext内容是如何从xxxx-serlvet.xml里面装载的。
initWebApplicationContext()中有这么一句:
WebApplicationContext parent = WebApplicationContextUtils.getWebApplicationContext(servletContext);然后在createWebApplicationContext()方法中有这么一句:wac.setParent(parent);由此可见，DispatcherServlet的WebApplicationContext的parent是在initWebApplicationContext()中得到，然后在createWebApplicationContext()方法中设置的。好奇的你也许会问，这个parent 实例到底是谁生成的呢，和/web-inf/applicationContext-hibernate.xml文件有什么关系呢.我们现在就来探讨一下这个问题。在spring工程中打开WebApplicationContextUtils的getWebApplicationContext()方法中只有那么一句:
return (WebApplicationContext) sc.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);也就是说，早就有人在web application的serlvet context里面设置好了这个属性,DispatcherServlet的initWebApplicationContext()只是利用WebApplicationContextUtils从servlet context把这个对象按名字检索出来而已。也许你已经按捺不住了，到底是谁设置了这个属性呢。
不用急，我们打开web.xml看看，在petclinic servlet的定义之前，还有一个servlet的定义:
<servlet>
   <servlet-name>context</servlet-name>
   <servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
   <load-on-startup>1</load-on-startup>
</servlet>
相信聪明的你已经从该servlet的名字和条目前面的注释猜出这个parent,也就是web application的root context是由ContextLoaderServlet来设置的。没错，从ContextLoaderServlet的init方法中我们可以发现,ContextLoaderServlet生成一个ContextLoader,并且调用其initWebApplicationContext()方法来设置root context。看看ContextLoader类，我们的答案都找到了。在其initWebApplicationContext()中，首先生成一个ApplicationContext作为root context的parent,呵呵，在root context之上没有context了，这个parent自然是null;而root context本身则在ContextLoader的createWebApplicationContext()方法里设置。该方法的步骤如下:

1.看在web.xml有没有定义定制的context类(用contextClass参数指出)，如果没有的话，就用XmlWebApplicationContext类来作为缺省的context类。在我们的这个petclinic工程里面，没有使用定制的context类，自然也就是用XmlWebApplicationContext类来作为context类了。
2.利用BeanUtils来生成一个context实例，在这里也就是一个XmlWebApplicationContext实例。
3.设置parent属性,也就是null;
4.设置servletContext属性，该属性还是从ContextLoaderServlet传过来的。
5.从web.xml中找到参数contextConfigLocation,作为配置文件的路径。我们在web.xml中定义contextConfigLocation的值是"/WEB-INF/applicationContext-hibernate.xml"
6.利用contextConfigLocation属性指出的xml配置文件中的内容刷新生成XmlWebApplicationContext实例。

呵呵，到此为止，关于web application的root context的出生问题已经搞清楚了，那么到底是谁把这个实例设置为servlet context的一个attribute的呢?呵呵，聪明的你肯定已经发现了ContextLoader的initWebApplicationContext方法中有这么一句:
WebApplicationContextUtils.publishWebApplicationContext(wac);没错，ContextLoader正是利用WebApplicationContextUtils把root context绑定为servlet context的一个属性的。至于这个属性叫什么名字，我想就不用我多说了。之所以让ContextLoaderServlet的load-on-startup=1，就是让这个servlet初始化web application的root context属性，绑定到servlet context.正如web.xml文中的注释指出的一样，如果你使用满足Servlet 2.4规范的容器，你就只需在web.xml中定义一个ContextLoaderListener就行了，而不用使用ContextLoaderServlet。

饶了这么大一个圈子，我们才明白了DispatcherServlet的WebApplicationContext的parent是如何来的。现在该说说DispatcherServlet的WebApplicationContext本身是如何设置的了。

现在我们来看看FrameworkServlet的createWebApplicationContext()方法。同ContextLoader的createWebApplicationContext()类似的步骤。不同之处在于前者含有wac.setNamespace(getNamespace());语句。通过跟踪getNamespace()我们得到FrameworkServlet的namespace属性其实就是字符串"[servletname]-serlvet"(servletname变量在web.xml中定义，对我们的petclinic工程而言就是petclinic)。接下来有这么一句:
if (this.contextConfigLocation != null){
    wac.setConfigLocations(WebApplicationContextUtils.parseContextConfigLocation(this.contextConfigLocation));

这个if语句会不会执行呢?也就是说FrameworkServlet的私有属性contextConfigLocation是不是为空呢?也就是有没有人给FrameworkServlet初始化这个属性呢?答案就在于FrameworkServlet的父类HttpServletBean的init()方法中，里面有这么一句PropertyValues pvs = new ServletConfigPropertyValues(getServletConfig(), this.requiredProperties);仔细研究ServletConfigPropertyValues()方法就知道，如
果你在web.xml给DispatcherServlet定义init-param参数contextConfigLocation的话(形式通常是诸如/WEB-INF/test-servlet.xml, /WEB-INF/myServlet.xml),父类方法init()中就会给FrameworkServlet初始化这个属性.在我们的petclinic工程并没有定义这个init-param参数,因此前面所说的if语句不会执行了。也就是FrameworkServlet的createWebApplicationContext()方法中的wac只是初始化了属性namespace,而没有初始化contextConfigLocation.接下来是wac.refresh();通过查看这个方法的源码(在XmlWebApplicationContext类中)我们就知道，在没有给XmlWebApplicationContext初始化contextConfigLocation属性的情况下，它会从namespace属性指出的xml配置文件中装载BeanDefinitions，我们的petclinic工程而言就是petclinic-servlet.xml文件。

至此为止,我们的WebApplicationContext终于生成了。回到FrameworkServlet的initWebApplicationContext()方法，我们可以发现，这个生成的WebApplicationContext以org.springframework.web.servlet.FrameworkServlet.CONTEXT.petclinic为key保存在ServletContext里面.再回到initServletBean(),我们要剖析下一个方法就是initFrameworkServlet(),该方法在DispatcherServlet中实现。典型的Template Method 
pattern!，在DispatcherServlet的initFrameworkServlet()中，有这么4句:

initMultipartResolver();
initLocaleResolver();
initThemeResolver();
initHandlerMappings();
initHandlerAdapters();
initHandlerExceptionResolvers();
initViewResolver();

这几个方法我们暂时不管，还是回到我们的老问题，看看DispatcherServlet是如何处理.htm结束的HttpRequest的吧。在FrameworkServlet的doGet()和doPost()都会调用serviceWrapper(),而serviceWrapper()又会调用doService(),因此，DispatcherServlet把所有的请求都用doService()来处理，doService()所做的工作，在spring-reference.pdf的9.2节有精确的阐述。我在这里只是剖析几个我们最关心的几个语句

1.request.setAttribute(WEB_APPLICATION_CONTEXT_ATTRIBUTE, getWebApplicationContext());
这个getWebApplicationContext()是在父类FrameworkServlet中定义的，返回的是我们在前面阐述的那个WebApplicationContext.

2.mappedHandler = getHandler(processedRequest);

该语句的作用是根据不同的请求，找到相应的handler。现在我们就来看看welcome.htm请求所对应的handler是什么。找到getHandler(),我们发现，getHandler()所做的就是在一个HandlerMapping的列表里面迭代查找，找到相对应的HandlerMapping，然后调用其getHandler返回一个HandlerExecutionChain.因此我们明白了，DispatcherServlet有一个HandlerMapping列表，列表里面都是HandlerMapping.对于HandlerMapping的getHandler()方法来说，如果该HandlerMapping能处理这种请求，他就会返回一HandlerExecutionChain,否则返回null.现在我们的任务就是找出DispatcherServlet的HandlerMapping列表是如何初始化的，welcome.htm请求到底是由哪个handerMaping处理的，该handerMaping的getHandler()返回的HandlerExecutionChain到底是个什么东西。

在DispatcherServlet的HandlerMapping列表是在其initHandlerMappings()方法中初始化的;在initHandlerMappings()方法中，我们可以看到，程序是利用Web ApplicationContext的BeanFactory的本质，在其BeanDefinitions中查找类型为HandlerMapping的bean,如果没有找到就用一个缺省的BeanNameUrlHandlerMapping().在我们的petclinic工程中HandlerMapping只有一个，就是在petclinic-servlet.xml中定义的id为urlMapping的SimpleUrlHandlerMapping。也就是说DispatcherServlet的HandlerMapping列表中只有一个SimpleUrlHandlerMapping对象(当然，其mappings属性会由beanFactory,也就是我们的WebApplicationContext根据petclinic-servlet.xml中的相应元素初始化好的)。因此关于DispatcherServlet的HandlerMapping列表的初始化问题已经解决了。接下来，我们要剖析SimpleUrlHandlerMapping类的getHandler()方法，来找出welcome.htm所对应的handler.我想这种追踪源码的方式大家都应该轻车熟路了。就像侦探破案一样，搜索的线路是:AbstractHandlerMapping.getHandler()--->A
bstractUrlHandlerMapping.getHandlerInternal()--->AbstractUrlHandlerMapping.lookupHandler("/welcome.htm")(在这里,log文件帮了大
忙)--->AbstractUrlHandlerMapping.lookupHandler()。lookupHandler()的作用就是从handlerMap里面找出对应的handler来。那么这个handleMap又是由谁在什么时候初始化的呢?从SimpleUrlHandlerMapping的initApplicationContext()来看，SimpleUrlHandlerMapping正是利用registerHandler()把从context配置文件传来的参数转化为对象存在handlerMap中的。你也许会说，到底是谁调用SimpleUrlHandlerMapping的initApplicationContext()呢?这里告诉你一个好方法，首先把petclinic-servlet.xml中id为urlMaping的bean的属性定义元素清除掉，然后利用ant重新发布,再访问petclinic首页，呵呵，正是你需要的StackTrace，重要的显示如下:

java.lang.IllegalArgumentException: Either 'urlMap' or 'mappings' is required at org.springframework.web.servlet.handler.SimpleUrlHandlerMapping.initApplicationContext(SimpleUrlHandlerMapping.java:62) at 
org.springframework.context.support.ApplicationObjectSupport.setApplicationContext(ApplicationObjectSupport.java:68) at 
org.springframework.context.config.ApplicationContextAwareProcessor.postProcessBean(ApplicationContextAwareProcessor.java:33) at org.springframework.beans.factory.support.AbstractBeanFactory.applyBeanPostProcessors(AbstractBeanFactory.java:834) at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.applyBeanPostProcessors(DefaultListableBeanFactory.java:186) at org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:550) at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:188) at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:211) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:280) at 
org.springframework.web.context.support.XmlWebApplicationContext.refresh(XmlWebApplicationContext.java:107) at 
org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:268) at 
org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:230) at 
org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:202) at 
org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:78) 

通过这个StackTrace，我想你终于明白了是谁调用SimpleUrlHandlerMapping的initApplicationContext()方法了吧。再通过剖析一下AbstractUrlHandlerMapping的registerHandler()，SimpleUrlHandlerMapping类的getHandler()方法就完全明白了。关于handler和interceptors的绑定问题，请从AbstractHandlerMapping中的语句return new HandlerExecutionChain(handler, this.interceptors)开始自行分析。


3.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

先看第一句，从DispatcherServlet的initHandlerAdapters()可以看出这个ha是一个SimpleControllerHandlerAdapter.再看第二句,首先找到SimpleControllerHandlerAdapter.handle(),再按图索骥找到AbstractController.handleRequest(),再找到MultiActionController的handleRequestInternal().该方法的流程是首先找到一个方法名，然后在MultiActionController的delegate对象上调用这个方法。因为我们没有在petclinic-servlet.xml定义ClinicController的delegate,所以这个delegage就是指ClinicController本身。现在问题的关键就是MultiActionController的methodNameResolver属性设置问题。

其实，看一看petclinic-servlet.xml中clinicController对clinicContr
ollerMethodNameResolver的引用你就会明白,clinicController的methodNameResolver是由WebApplicationContext设置的，它是一个PropertiesMethodNameResolver。因为在MultiActionController的handleRequestInternal()方法中调用了methodNameResolver.getHandlerMethodName(request);找到PropertiesMethodNameResolver的源代码看,里面果然有mapings属性，和web.xml中的属性定义对应起来了，/welcome.htm请求对应的方法就是welcomeHandler。然后我们把目光转到MultiActionController的invokeNamedMethod方法，从return (ModelAndView) m.invoke(this.delegate, parray);来看，无非就是激活clinicController的welcomeHandler().再看看clinicController的welcomeHandler();只有一句话:return new ModelAndView("welcomeView");至此我们终于知道mv是怎么来的了。


4.render(mv, processedRequest, response, locale);
顾名思义, 该方法就是把从第三步得到的ModelAndView表现出来。从clinicController的welcomeHandler()中mv的创建来看，这个mv是一个Reference，因为其viewName不为空，DispatcherServlet的render()中的view = this.viewResolver.resolveViewName(mv.getViewName(), locale);语句肯定会执行。从DispatcherServlet的initViewResolver()可以看到WebApplicationContext是根据beanName,也就是"viewResolver"给Dispatcher
Servlet初始化viewResolver属性的。从petclinic-servlet.xml可以发现这个viewResolver是个ResourceBundleViewResolver。于是，我们找到ResourceBundleViewResolver的resolveViewName()方法.这里又要做一番来来回回的代码追踪工作了。我简单的说一下吧:因为ResourceBundleViewResolver的basename属性被WebApplicationContext设置为"views"(其实不在petclinic-servlet.xml中设置也可以，因为缺省值就是"views")
这样在initFactory()中，程序就会在classpath中根据locale查找合适的views_xx形式的properties文件，生成beanFactory(关于locale的由来，请从DispatcherServlet的initLocaleResolver()处找到答案)。我们这里的locale肯定是zh_CN了。在我们的类路径下面并没有views_zh_CN,我们只要看缺省的views.properties文件，该文件位于src目录下面。看到这个文件，我想initFactory()生成的beanFactory的内容我们就全
明白了。ResourceBundleViewResolver的resolveViewName()最终会把任务落到其loadView()方法上。从views.properties得知,该方法返回的view的类别是org.springframework.web.servlet.view.JstlView，其url属性是/WEB-INF/jsp/welcome.jsp.好了，让我再回到DispatcherServlet的render()方法，最后的那一句是:view.render(mv.getModel(), request, response);现在我们就来找找org.springframework.web.servlet.view.JstlView的render方法。又是一个Template design pattern.跟踪的路线是:org.springframework.web.servlet.view.render--->InternalResourceView.renderMergedOutputModel().在这个方法中，我们找到了最熟悉不过的代码:
.........................
RequestDispatcher rd = request.getRequestDispatcher(getUrl());
.........................
rd.forward(request, response);

其中JstlView的url属性是WebApplicationContext利用AbstractUrlBasedView定义的setUrl()，根据views.properties中的bean定义设置的。

至此为止，我们终于弄明白了petclinic web application的首页的来龙去脉了。我们对spring的mvc也有了一个初步体验了。关于mvc的其他细节我会在续篇中推出。