既然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的其他细节我会在续篇中推出。
附:源码
- /*
- * Copyright 2002-2004 the original author or authors.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
- package org.springframework.web.context.support;
- import javax.servlet.ServletContext;
- import org.springframework.web.context.WebApplicationContext;
- /**
- * Convenience methods to retrieve the root WebApplicationContext for a given
- * ServletContext. This is e.g. useful for accessing a Spring context from
- * within custom web views or Struts actions.
- * @author Juergen Hoeller
- * @version $Id: WebApplicationContextUtils.java,v 1.10 2004/03/22 10:32:17 jhoeller Exp $
- * @see org.springframework.web.context.ContextLoader
- */
- public abstract class WebApplicationContextUtils {
- /**
- * Find the root WebApplicationContext for this web app, which is
- * typically loaded via ContextLoaderListener or ContextLoaderServlet.
- * @param sc ServletContext to find the web application context for
- * @return the root WebApplicationContext for this web app, or null if none
- * @see org.springframework.web.context.WebApplicationContext#ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE
- */
- public static WebApplicationContext getWebApplicationContext(ServletContext sc) {
- Object attr = sc.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
- if (attr == null) {
- return null;
- }
- if (attr instanceof RuntimeException) {
- throw (RuntimeException) attr;
- }
- if (attr instanceof Error) {
- throw (Error) attr;
- }
- if (!(attr instanceof WebApplicationContext)) {
- throw new IllegalStateException("Root context attribute is not of type WebApplicationContext: " + attr);
- }
- return (WebApplicationContext) attr;
- }
- /**
- * Find the root WebApplicationContext for this web app, which is
- * typically loaded via ContextLoaderListener or ContextLoaderServlet.
- * @param sc ServletContext to find the web application context for
- * @return the root WebApplicationContext for this web app
- * @throws IllegalStateException if the root WebApplicationContext could not be found
- * @see org.springframework.web.context.WebApplicationContext#ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE
- */
- public static WebApplicationContext getRequiredWebApplicationContext(ServletContext sc)
- throws IllegalStateException {
- WebApplicationContext wac = getWebApplicationContext(sc);
- if (wac == null) {
- throw new IllegalStateException("No WebApplicationContext found: no ContextLoaderListener registered?");
- }
- return wac;
- }
- }