怎么样根据petclinic项目剖析springframework源代码？
怎么样根据petclinic项目剖析springframework源代码？
既然petclinic是个webapplication,我们当然从web.xml文件入手了。首先当然welcome-file-list条目了，该条目指出index.jsp是网站的入口。index.jsp写得很简单，只有3行。如下所示:<%@includefile="/web-inf/jsp/includes.jsp"%>
<%--redirectedbecausewecan'tsetthewelcomepagetoavirtualurl.--%>
<c:redirecturl="/welcome.htm"/>
第一行是一条include指令，包括了一个includes.jsp,该jsp文件里面有webapplication用到的标记库的全部声明语句。因此第三条语句c:redirect就用的很自然了，从该语句可以看到，webcontainer把请求重定向为/welcome.htm请求了。再查看一下web.xml,有这么一段:
<servlet-mapping>
<servlet-name>petclinic</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
由此，我们可知，webcontainer把匹配*.htm的请求都交给petclinicservlet也就是org.springframework.web.servlet.dispatcherservlet来处理了。dispatcherservlet是研究springframeworkmvc的关键类，在你的spring工程中打开该类的源代码吧。
在你spring工程中你可以看到,dispatcherservlet的父类是frameworkservlet,frameworkservlet的父类httpservletbean,而httpservletbean的父类是httpservlet,因此dispatcherservlet本质上是个httpservlet.在web.xml中的<load-on-startup>2</load-on-startup>表明,jspcontainer在启动的时候就会生成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有一个parentwebapplicationcontext,这个parent是整个webapplication的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()中有这么一句:
webapplicationcontextparent=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);也就是说，早就有人在webapplication的serlvetcontext里面设置好了这个属性,dispatcherservlet的initwebapplicationcontext()只是利用webapplicationcontextutils从servletcontext把这个对象按名字检索出来而已。也许你已经按捺不住了，到底是谁设置了这个属性呢。
不用急，我们打开web.xml看看，在petclinicservlet的定义之前，还有一个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,也就是webapplication的rootcontext是由contextloaderservlet来设置的。没错，从contextloaderservlet的init方法中我们可以发现,contextloaderservlet生成一个contextloader,并且调用其initwebapplicationcontext()方法来设置rootcontext。看看contextloader类，我们的答案都找到了。在其initwebapplicationcontext()中，首先生成一个applicationcontext作为rootcontext的parent,呵呵，在rootcontext之上没有context了，这个parent自然是null;而rootcontext本身则在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实例。
呵呵，到此为止，关于webapplication的rootcontext的出生问题已经搞清楚了，那么到底是谁把这个实例设置为servletcontext的一个attribute的呢@呵呵，聪明的你肯定已经发现了contextloader的initwebapplicationcontext方法中有这么一句:
webapplicationcontextutils.publishwebapplicationcontext(wac);没错，contextloader正是利用webapplicationcontextutils把rootcontext绑定为servletcontext的一个属性的。至于这个属性叫什么名字，我想就不用我多说了。之所以让contextloaderservlet的load-on-startup=1，就是让这个servlet初始化webapplication的rootcontext属性，绑定到servletcontext.正如web.xml文中的注释指出的一样，如果你使用满足servlet2.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()方法中，里面有这么一句propertyvaluespvs=newservletconfigpropertyvalues(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中实现。典型的templatemethod
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()方法中，我们可以看到，程序是利用webapplicationcontext的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'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，我想你终于明白了是谁调用simpleurlhandlermapping的initapplicationcontext()方法了吧。再通过剖析一下abstracturlhandlermapping的registerhandler()，simpleurlhandlermapping类的gethandler()方法就完全明白了。关于handler和interceptors的绑定问题，请从abstracthandlermapping中的语句returnnewhandlerexecutionchain(handler,this.interceptors)开始自行分析。
3.
handleradapterha=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();只有一句话:returnnewmodelandview("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方法。又是一个templatedesignpattern.跟踪的路线是:org.springframework.web.servlet.view.render--->internalresourceview.rendermergedoutputmodel().在这个方法中，我们找到了最熟悉不过的代码:
.........................
requestdispatcherrd=request.getrequestdispatcher(geturl());
.........................
rd.forward(request,response);
其中jstlview的url属性是webapplicationcontext利用abstracturlbasedview定义的seturl()，根据views.properties中的bean定义设置的。
至此为止，我们终于弄明白了petclinicwebapplication的首页的来龙去脉了。我们对spring的mvc也有了一个初步体验了。