Spring原代码分析(ZT)

第 一行是一条include指令&＃xff0c;包括了一个includes.jsp,该jsp文件里面有webapplication用到的标记库的全部声明语句。因 此第三条语句c:redirect就用的很自然了&＃xff0c;从该语句可以看到&＃xff0c;webcontainer把请求重定向为/welcome.htm请求了。再查看 一下web.xml,有这么一段:

petclinic
*.htm

由 此&＃xff0c;我们可知&＃xff0c;webcontainer把匹配*.htm的请求都交给petclinicservlet也就是 org.springframework.web.servlet.DispatcherServlet来处理了。DispatcherServlet是 研究SpringFrameworkmvc的关键类&＃xff0c;在你的spring工程中打开该类的源代码吧。

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

context
org.springframework.web.context.ContextLoaderServlet
1

相 信聪明的你已经从该servlet的名字和条目前面的注释猜出这个parent,也就是webapplication的rootcontext是由 ContextLoaderServlet来设置的。没错&＃xff0c;从ContextLoaderServlet的init方法中我们可以发现, ContextLoaderServlet生成一个ContextLoader,并且调用其initWebApplicationContext()方法 来设置rootcontext。看看ContextLoader类&＃xff0c;我们的答案都找到了。在其initWebApplicationContext() 中&＃xff0c;首先生成一个ApplicationContext作为rootcontext的parent,呵呵&＃xff0c;在rootcontext之上没有 context了&＃xff0c;这个parent自然是null;而rootcontext本身则在ContextLoader的 createWebApplicationContext()方法里设置。该方法的步骤如下:

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

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

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

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

这 个if语句会不会执行呢?也就是说FrameworkServlet的私有属性contextConfigLocation是不是为空呢?也就是有没有人 给FrameworkServlet初始化这个属性呢?答案就在于FrameworkServlet的父类HttpServletBean的init() 方法中&＃xff0c;里面有这么一句PropertyValuespvs&＃61;newServletConfigPropertyValues (getServletConfig(),this.requiredProperties);仔细研究 ServletConfigPropertyValues()方法就知道&＃xff0c;如
果你在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类中)我们就知道&＃xff0c;在没有给XmlWebApplicationContext初始化 contextConfigLocation属性的情况下&＃xff0c;它会从namespace属性指出的xml配置文件中装载BeanDefinitions&＃xff0c;我 们的petclinic工程而言就是petclinic-servlet.xml文件。

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

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

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

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

2.mappedHandler&＃61;getHandler(processedRequest);

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

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

java.lang.IllegalArgumentException:Either&＃39;urlMap&＃39;or&＃39;mappings&＃39;isrequiredatorg.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)atorg.springframework.beans.factory.support.AbstractBeanFactory.applyBeanPostProcessors(AbstractBeanFactory.java:834)at
org.springframework.beans.factory.support.DefaultListableBeanFactory.applyBeanPostProcessors(DefaultListableBeanFactory.java:186)atorg.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)atorg.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&＃xff0c;我想你终于明白了是谁调用SimpleUrlHandlerMapping的initApplicationContext ()方法了吧。再通过剖析一下AbstractUrlHandlerMapping的registerHandler()&＃xff0c; SimpleUrlHandlerMapping类的getHandler()方法就完全明白了。关于handler和interceptors的绑定问 题&＃xff0c;请从AbstractHandlerMapping中的语句returnnewHandlerExecutionChain(handler, this.interceptors)开始自行分析。


3.
HandlerAdapterha&＃61;getHandlerAdapter(mappedHandler.getHandler());
mv&＃61;ha.handle(processedRequest,response,mappedHandler.getHandler());

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

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


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

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

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