45fan.com - 路饭网

搜索: 您的位置主页 > 网络频道 > 阅读资讯:怎么样根据petclinic项目剖析springframework源代码?

怎么样根据petclinic项目剖析springframework源代码?

2016-09-05 11:33:01 来源:www.45fan.com 【

怎么样根据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也有了一个初步体验了。
 

本文地址:http://www.45fan.com/a/question/72620.html
Tags: 项目 根据 petclinic
编辑:路饭网
关于我们 | 联系我们 | 友情链接 | 网站地图 | Sitemap | App | 返回顶部