第八章 Dispatching Requests
当建立一个web应用时，把一个请求传给另一个servlet或在response中包含另一个servlet的输出是经常
使用的。RequestDispatcher接口就提供了一些方法。
8.1 获得RequestDispatcher
实现了接口RequesetDispatcher接口的对象可以在ServletContext的getRequestDispatcher或
getNamedDispatchcer方法得到。
getRequestDispatcher的参数是一个以根目录‘/’开始的一个路径，该方法会查找路径下的servlet，并把
它封装成RequestDispatchcer对象返回。
getNamedDispatcher方法把一个ServletContext知道的servlet名字作为参数，如果找到servlet，该
servlet就被封装成RequestDispatcher对象返回，如果没有找到则返回null。
RequestDispatcher对象中使用相对路径也是可以的。在ServletRequest中提供了getRequestDispatcher
方法；这个方法和ServletContext中同名的方法功能类似。servlet引擎会用request的信息把相对路径转
化成完整路径的。如ServleltRequest.getRequestDispatcher("header.html")和ServletConext.
getRequestDispatcher("/garden/headere.html")是等效的。
8.1.1 在Request Dispatcher 路径中附加字符串
在ServletContext和ServletRequest创建RequestDispatcher方法中参数都可以带字符串如：
Context.getRequestDispatcher("/raisons.jsp?orderno=5");
8.2 Request Dispatcher的使用
对于使用Request Dispatcher 而言就是一个servlet调用include或forward方法，这些方法的参数是
Servlet接口传来的request和response对象实例。引擎必须确保调用Request Dispatcher的处理过程是在
同一个JVM的同一个线程中。
8.3 include 方法
RequestDispatcher接口的include方法可以在任何时候被调用；目标servlet可以包含所有外的request对
象，不过response对象的使用是有限制的：
response只能写信息到ServletOutputStream 或者Writer中，调用response对象的flushBuffer方法进行提
交。不能够设置头信息，任何方法都不会影响到response的头信息。
8.3.1 被包含的request参数
除了可以用getNamedDispatcher方法包含一个servlet外，以下的属性可以被设置：
Java.servlet.include.request_uri
Java.servlet.include.context_path
Java.servlet.include.servlet_path
Java.servlet.include.path_info
Java.servlet.include.query_string
用request对象的getAttribute方法可以获取被包含servlet的以上属性。
如果被包含的servlet能后通过getNamedDispatcher方法找到就不必设置以上属性了。
8.4 Forward 方法
RequestDispatcher接口中的forward方法，只有servlet没有提交响应到客户端时才可用；如果响应
buffer中有数据还没有提交，当调用forward方法中目标servlet的service方法前，buffer中的内容会被清
空；如果buffer中的数据提交了，则发生IllegalStateException错误。
request对象的路径必须放映获取RequestDispatcher对象的路径。
有个例外，如果RequestDispatcher是通过getNamedDispatcher方法得到的，request对象必须反映原始
request的路径。
在RequestDispatcher接口方法forward返回前，response的内容必须被提交，并由引擎关闭该servlet。
8.4.1 query String
在Request Dispatcher中创建的路径是可以带参数的。
8.5 错误
如果request Dispatcher的目标servlet抛出运行时错误或ServletException 或IOException，错误就会被
传给调用的servlet；在上传之到调用的servlet之前，所有其他的exception都应该包装成
ServletExceptions。
第九章 web 应用
一个web应用是一堆servlet，html页面，类和其他资源的集合。web应用可以被发布运行在很多服务提
供商的多种引擎下。
9.1 web服务器
在web服务中一个web应用的根目录是一个特殊的路径，例如：一个网站目录可以以http://www.
mycorp.com/登录，所有的请求都将以这个作为前缀发送到以这个前缀描述的servletContext环境中。
在任何时候一个web应用的实例只能运行在一个JVM中。
9.2 和servletContext的关系
servlet引擎会强迫web应用和ServletContext的通信，一个ServletContext对象提供了一个servlet使得该
应用可见。
9.3 web应用中的元素
一个web应用包含以下的元素：
.Servlets
.JSP
.Utility Classes
.Static documents(html,images,sounds,etc)
.Client side Java applets,beans,and classes
.Descriptive meta informateion
9.4 部署层次
这个协议定义了一个层次结构，用于部署和打包，这个结构存在于一个文件中。
9.5 目录结构
一个web应用存在一个目录层次结构。文件根目录是应用的一部分。例如：一个web应用的上下文路径
是/catalog，web应用的index.html文件就能被/catalog/index.html请求访问。URL和上下文路径的匹配
规则将在11章讨论。servlet引擎必须拒绝一个具有现在冲突的上下文路径的web应用，这种情况是有
的，如：两个web应用发布在同一个上下文路径中，或一个web应用的上下文路径是另一个web应用上
下文路径的子路径。
有一个特殊的目录（“WEB-INF”）在应用中存在，这个目录包含所有与应用相关，又不在根目录中的事
物。可以直接被引擎提供给客户端的文件不放在WEB-INF中，但WEB-INF目录对于调用ServletContext
的getResource和getResourceAsStream方法的servlet 代码是有效的。如果开发者想用servlet代码调用
一个不希望暴露给客户端的一个配置信息，就可以把这个配置信息放在WEB-INF目录下。请求都是和资
源相匹配的；敏感的匹配如客户端的请求是“/WEB-INF/foo”和“/Web-iNf/foo”，但不应该把定位于/
WEB-INF下的内容作为结果返回。
WEB-INF目录下的内容有：
./WEB-INF/web.xml 部署描述文件
./WEB-INF/classes/ 存放servlet class
./WEB-INF/lib/*.jar 是jar包的目录
应用的classloader先load WEB-INF/classes目录下的class后load WEB-INF/lib目录下的jar包
9.5.1 目录结构的一个例子
一个简单web应用的目录结构：
/index.html
/howto.jsp
/images/banner.gif
/images/jumping.gif
/WEB-INF/web.xml
/WEB-INF/lib/jspbean.jar
/WEB-INF/classes/com/mycorp/servlets/MyServlet.class
/WEB-INF/classes/com/util/MyUtils.class
9.6 web应用的存档文件
一个web应用可以被java打包工具打包成war文件，当被打包后包中就会有一个额外META-INF目录，该
目录下存放了打包工具的一些信息。
9.7 web应用部署描述
下面是web应用部署描述中的配置类型：
.ServletContext Init Parameters
.Session Configuration
.Servlet / JSP Definitions
.Servlet / JSP Mappings
.MIME Type Mappings
.Welcome File list
.Error Pages
.Security
9.7.1 可靠的扩展
web容器须提供一种机制使得web应用知道jar文件中包含的有用资源或代码。
引擎因该提供编辑、配置库文件的程序。
在WAR中提供一个MANIFEST.MF文件，描述扩展名列表是比较好的。标准的JAR是应该有的，这个文件
描述的扩展名应该遵循Http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html中的规
定。web容器应该能够识别WEB-INF/lib文件夹中的任何文件的扩展名，如果不能够识别就应该拒绝该
应用程序，并报出错误。
9.7.2 web应用的classloader
引擎用于装载war中的servlet的装载器必须能够让开发者装载jar库中的任何资源。但装载的资源禁止覆
盖j2se或servlet API中的类；通常建议的做法是装载器不允许war中的servlet去访问web引擎中的类。
还有一个被推荐的做法是实现应用类装载器，war中被装载的类或资源就会被放到container-wide JAR库
的特定类或资源中。
9.8 替换web应用
一个服务器可能会在不重新启动引擎的情况下用一个新版本的应用替换原有的应用。当一个应用被替换
时，引擎应提供一个robust方法去保存该应用中的session
9.9 错误句柄
9.9.1 request Attributes
web应用必须列出在使用中资源发生的错误，这些资源在部署描述中都有定义。
如果错误在一个servlet或一个jsp页面中发生，则在第9.1章中的如下的请求属性就会被设置：
Request Attributes Type
Javax.servlet.error.status_code java.lang.Integer
Javax.servlet.error.exception_type java.lang.Class
Javax.servlet.error.message java.lang.String
Javax.servlet.error.exception java.lang.Throwable
Javax.servlet.error.request_uri java.lang.String
Javax.servlet.error.servlet_name java.lang.String
这些属性允许这个servlet根据这些状态码、错误类型、错误信息、被抛出的错误对象、错误产生的
servlet被访问的URI（可以用getRequestURI得到）、或错误产生的servlet的逻辑名称产生特殊的内
容。
在2.3版本中错误类型和错误信息属性是多余的，他们被保留只是为了向下兼容以前的版本。
9.9.2 错误页面
当一个servlet产生错误时，开发者可以订制错误内容返回给客户端。部署描述文件定义了一个错误页面
列表。servlet在response中设置错误状态码或产生的异常或错误被引擎支持时，引擎就会从部署描述文
件中调用相应的配置的错误资源。
如果一个错误码被设置在了response中，引擎在部署描述文件的错误页面列表中用status-code方式匹配
对应的资源，如果找到就调用本地的资源。
在一个请求被处理的过程中servlet可以抛出以下的异常：
.runtime exceptions or errors
.ServletExceptions or subclasses thereof
.IOException or subclasses thereof
web应用可以用exception-type元素来描述错误页面，在这种情况下引擎会通过比较用exception-type元
素定义的error-page列表中的异常来匹配产生的异常。匹配的结果是返回定义的与错误匹配的本地资
源。在继承类中，最近的类将被调用。
如果没有一个error-page包含的exception-type与class-heirarchy相匹配。抛出的ServletException或其子
类异常，被引擎通过ServletException.getRootCause方法获得，获得后用这个异常再去配置的error
page列表中去匹配。
在部署描述文件中用exception-type元素定义的Error-page中exception-type的类名必须是唯一的。
当错误发生在servlet调用的RequestDispatcher中时error page机制是不能够干预到的；这样的情况如：
一个servlet用RequestDispatcher去调用另一个有错误的servlet。
如果一个servlet产生的错误没有被描述的错误页面机制所抓到，引擎必须设置response的状态码为500
9.10 Welcome Files
web应用可以在部署描述文件中定义一个welcome files调用的URI列表，这个机制的目的是允许开发者
定义自己的访问首页。
如果没有在部署描述中配置welcome 文件,引擎将把局部请求（没有指明具体访问资源，如www.cacolg.
com/index.html,请求访问时用www.cacolg.com/访问的）发送到适当的资源中，如：一个可能默认的
servlet，或列出该目录下的文件列表，或返回404响应错误。
一个例子：
1）在部署描述中定义index.html和default.jsp为welcome files
2）定义一个servlet的mapping路径为/foo/
WAR中有的文件如下：
/foo/index.html
/foo/default.html
/foo/orderform.html
/foo/home.gif
/catalog/default.jsp
/catalog/products/shop.jsp
/catalog/products/register.jsp
3）请求的URI为 处理后的URI
/foo 或 /foo/ /foo/index.html
/catalog/ /catalog/default.jsp
/catalog/index.html 404 not found
/catalog/products/ 404 not found 也可能返回shop.jsp and /or register.jsp 列表。
9.11 web应用环境
j2EE定义的命名环境能够使得应用在不需要知道外部信息怎么命名的情况下比较方便的访问资源或外部
信息。
servlet作为j2EE完整的一部分，使web应用部署描述文件提供了一个servlet可以访问资源和EJB，这些
部署描述元素有：
.env-entry
.ejb-ref
.ejb-local-ref
.resource-ref
.resource-env-ref
开发者使用这些元素描述web应用中需要用到的对象，这些对象都要在web容器运行时注册到JNDI命名
空间。
在J2EE1.3版本j2EE的环境需求中，servlet引擎不是J2EE技术的一部分，web环境要提供的功能在J2EE
规范中有描述。如果没有实现支持环境所要提供的功能，在发布应用时，web容器就会抛出警告。
实现servlet引擎在J2EE中是需要的，应该被纳入J2EE1.3中。J2EE1.3应该提供更多的内容。
servlet引擎必须支持对象的lookup方法，查找对象并在引擎控制的线程中实例化。
servlet引擎应该支持开发者创建的线程，因为应用创建的线程不是很轻便，开开发者不得不依赖于这些
功能有限的线程。这些需求将被加入到下一个版本的servlet规范中。
第十章 应用周期事件
10.1 介绍
事件是servlet2.3种新添的内容。应用事件使得web开发者能够控制ServletContext和HttpSession对象的
信息交互，使得管理web使用的资源更有效，方便。
10.2 事件监听器
事件监听器是实现了servlet事件监听接口的类。在web发布是这些监听类就被实例化和注册在web容器
中。
servlet事件监听器提供了在ServletContext和HttpSerssion对象状态发生改变时触发的事件。Servlet
cotext监听器用于管理应用的资源或虚拟机的状态。HTTP session监听器管理与会话关联的资源。
可以有多个监听器监听每一个事件类型。开发者可以指定引擎调用监听类的顺序。
10.2.1 事件类型和监听接口
Event Type ListenerInterface 说明
Lifecycle javax.servlet.ServletContextListener 当servlet context被创建并有效的
接受第一个请或servlet context销毁前
Changes to attributees javax.servlet.ServletContextAttributesListener 当servlet context中的属性发生
added,removed,replaced
Lifecycle javax.servlet.http.HttpSessionListener 当HttpSession被创建，无效或超时
Changes to attributes javax.servlet.HttpSessionAttributesListener 当属性added,removed或replaced时
10.2.2 一个使用监听的例子
一个简单的web应用中有servlet要访问数据库，开发者提供一个context 监听类管理数据库连接。
1）web应用启动时，监听类被装载，登陆数据库，在servlet context中保存数据库连接。
2）servlet访问数据库连接
3）当web服务销毁时，或应用从web服务中删除时，关闭数据库连接。
10.3 监听类的配置
10.3.1 对监听类的规定
web开发者提供实现了以上监听接口的类，每个类应该有一个没有参数的构造器函数。监听类放在
WEB-INF/classes下或以一个jar文件放在WEB-INF/lib下都可以。
10.3.2 部署描述
web容器对每个监听类只会创建一个实例，在第一个请求到来之前实例化并注册。web容器注册监听类
的顺序根据他们实现的接口和在部署描述文件中定义的顺序。web应用调用监听实例的顺序按照他们注
册的顺序。
10.3.4 在销毁时的事件
当应用销毁时监听事件的执行顺序按部署描述中的顺序，先执行session中的监听事件再执行context中
的监听事件。session的无效事件必须在context的销毁事件之前被调用。
10.4 部署描述的例子
下面给出注册两个servlet cocntext lifecycle监听器和一个HttpSession监听器的例子。
Com.acme.MyconnectionManager和com.acme.MyLoggingMoudule都实现了javax.
servletServletContextListener接口,com.acme.MyloggingModule另外还实现了javax.servlet.
HttpSessionListener接口。开发者希望com.acme.MyConnectionManager在com.acme.
MyLoggingModule之前管理者servlet context 的生命周期事件。部署描述文件如下：
<web-app>
<display-name>MyListeningApplication</display-name>
<listener>
<listener-class>com.acme.MyConnectionManager</listener-class>
</listenrer>
<listenrer>
<listenrer-class>com.acme.MyLoggingModele</listener-class>
</listener>
<sevlet>
<display-name>RegistrationServlet</display-name>
..etc
</servlet>
</web-app>
10.5 监听器的实例和线程
在第一个请求被web容器接受之前实例化并注册好监听器类是必须的。监听器在整个web应用生命周期
中都要使用。
ServletContext和HttpSession对象属性的改变可能会同时产生，引擎不需要同步这些属性类的事件。
10.6 分布式容器组
在分布式web容器组中，HttpSession和ServletContext实例只活动与它们本地的JVM中。在分布式web容
器中，监听实例会在每一个web容器中创建实例。
10.7 session事件
监听器使得开发者可以跟踪web应用中的session。知道session是否变得无效是经常被用到的，因为
session超时时引擎会使session变得无效，或应用会调用invalidate方法。