在HTTP协议中，当客户端不再有效时，没有清楚的定义终止信号。这就意味着通常只能采用时间超时
来表明客户端不再有效。
默认的超时时间是servlet引擎定义的，通过HttpSession的getMaxInactiveInterval方法可以得到超时的
时间；开发者可用用setMaxInactiveInterval方法来设置超时的时间，以秒定义的。如果一个session的
超时时间被设置为-1，则这个session将永远有效。
7.6 最后访问时间
在当前的请求中用HttpSession接口的getLastAccessedTime可以获得最后一次访问session的时间。
7.7 重要session
7.7.1 线程问题
在一个可以配置的应用中，所有的请求都是一个会话的一部分，引擎一定能够取出通过setAttribute或
putValue放入HttpSession对象中的对象。注意以下的情况：
.引擎一定能够访问实现了Serializable接口的对象。
.引擎可以选择存储HttpSession对象中指定的对象，如EJB组件和事务。
.引擎能够监听到会话的变动。
如果放入session中的对象没有被Seializable或没有效，servlet可以抛出IllegalArgumentException；如果
引擎不支持Session存储对象的机制，引擎一定会抛出IllegalArgumentException。
这些限制意味着，在一个分布式引擎中，不会有额外的并发问题。
如果引擎为了service的品质持续化或迁移session，使用本地持续化的HttpSession或它的属性是不受限
制的，开发者要想确保放入session中的属性对象能够可用，最好对象实现Serializable接口。
在迁移一个session时引擎必须通知session中实现了HttpSessinActivationListener的属性对象，必须通知
在序列化前钝化的或序列化后激活的session的监听器。
开发分布式的开发者应该清楚的是，一旦引擎运行在超过一个JVM的时候，就不能用static 表明变量来
存储应用状态，应该用EJB或数据库赖存储。
7.7.3客户端
因为cookies或SSL证书都是被web浏览器访问过程控制的，与任何特殊的window浏览器是没有关系的。
所以从所有window客户端到一个servlet引擎的请求是同一个会话的一部分。最好是开发者总是设想所
有的window客户端是一起参与同一个会话的。

符串，如果上下文路径不是web服务的根目录，则路径以‘/’字符开始，但不能以‘/’结束。
Servlet 路径：与该请求匹配的servlet的路径。该路径以‘/’字符开头，或以‘/*’开头但后面为空字
串。
路径信息：是请求路径的一部分，但不是context路径的一部分，也不是Servlet路径的一部分，
它既不为null也不是以‘/’开头的字符串。
上一路径在HttpServletRequest接口中对应的方法是：
getContextPath
getServletPath
getPathInfo
requestURI = contextPath + servletPath + pathInfo
上下文配置的例子：
Conteext Path /catalog
Servlet Mapping Pattern:/lawn/*
Servlet:LawnServlet
Servlet Mapping Pattern:/garden/*
Servlet:GardenServlet
Servlet Mapping Pattern:*.jsp
Servlet:JSPServlet
观察下面的路径
Request path path Elements
/catalog/lawn/index.htm ContextPath:/catalog
ServletPath:/lawn
PathInfo:/index.html
/catalog/garden/implements/
ContextPath:/catalog
ServletPath:/garden
PathInfo:/implements/
/catalog/help/feedback.jsp
ContextPath:/catalog
ServletPath:/help/feedback.jsp
PathInfo:null
4.5 路径转换
在API中有两个简单的方法允许开发者获得文件系统的路径：
ServletContext.getRealPath
HttpServletRequet.getPathTranslated
getRealPath(String aPath)方法返回本地文件系统的绝对路径。getPathTranslated方法计算出请
求pathInfo中的绝对路径。
以上的两个方法，servlet引擎不能辨认文件的路径是否有效，当web应用调用一个不确定远程
文件系统，或数据库路径中的文件时，会返回null
4.6 Cookies
HttpServletRequest接口中提供了getCookies方法返回请求中的cookies数组，在每次客户端请求
时cookies数据就从客户端发送给服务。客户端返还的部分cookie信息是cookie的name和cookie
的value。当cookie被送入浏览器时，cookie的其它信息就可以设置了。
4.7 SSL 属性
如果一个请求被转给一个安全的协议，如HTTPS，这些信息必须暴露给ServletRequest接口的
isSecure方法。web引擎必须把下面的信息暴露给servlet开发者：
Attribute Attribute Name javaType
Cipher suite javax.servlet.request.cipher_suite String
bit size of the algo-rithm javax.servlet.request.key_size Integer
如果一个SSL证书伴随着一个请求，servlet引擎必须把它作为一个数组对象暴露给servlet开发
者，该数组中有
java.security.cert.X509Certificate对象和放在ServletRequest属性中的javax.servlet.request.
X509Certificate对象。
数组排列的顺序是升序，在链中的证书的顺序就是客户端设置的顺序。
4.8 国际化
ServletRequest接口的方法中提供了的方法：
getLocale
getLocales
getLocale方法将返回客户端将从中获得内容的首选的locale。要想知道更多的关于Accept-
Language header 怎么解释客户端首选的语言的，请看14.4章
getLocales方法返回一个Locale objects的Enumeration,从首选的locale开始递减。
如果客户端没有制定首选的locale，servlet引擎一定要提供一个默认的locale供getLocale方法返
回，getLocales方法必须包含一个默认的locale的locale element
4.9 Request 数据的编码
有许多web浏览器不能发送一个编码的头内容，所以把编码留给解读HTTP请求的Read去做。对
于默认的请求编码，引擎通常创建一个reader用“ISO-8859-1”去解析POST的数据，如果客户端
没有指明编码，或者客户端发送失败，getCharacterEncoding方法就返回null。
如果客户端没有设置编码，而请求需被另外一种编码，可用ServletRequest接口中的
setCharacterEncoding(String enc) 方法。必须在解析post数据或读取请求流之前调用这些方
法。
4.10 Request对象的生命周期
每个request对象仅在servlet的service方法或filter中的doFilter方法中有效，引擎重用request对
象是为了降低创建request对象的性能消耗。
开发者必须清楚request对象在给定的范围外的一些不确定的行为。
                                                                      第五章
response对象封装着服务端送给客户端的信息，从服务端传回的信息可以包含在请求的头和消息体重。
5.1 缓存
servlet引擎支持应答缓存，典型的servlet会默认的执行缓存，servlet可以指定缓存参数。
设置缓存信息的方法在ServletResponse接口中的方法有：
getBufferSize
setBufferSize
isCommitted
Reset
resetBuffer
flushBuffer
这些方法只有在servlet调用ServletOutputStream 或Writer之前有效。
getBufferSize返回缓存的大小，如果没有缓存，该方法返回0。
setBufferSize可以设置缓存的大小，但不是必须的。servlet会根据请求放置适当的缓存大小。这方
法必须在servlet调用ServletOutputStream 或Writer方法之前被调用。如果在之后调用就会抛出
IllegalStateException错误。
isCommitted返回一个boolen值，标志是否有任何一个字节的数据被返回给客户端了。flushBuffer
方法强制把缓存中的信息写到客户端。
当response没有提交缓存内容时调用reset方法就会清除缓存中的信息，包括头信息和状态码。
resetBuffer方法会清除缓存中的信息，但不会清除头和状态码。在commit之后调用reset或
resetBuffer都会抛出IllegalStateException错误，缓存中的内容不受影响。
使用缓存时，当缓存满时response就必须立刻刷新把缓存中的内容发送给客户端；只要第一个字节
到了客户端，commit的状态就为true。
5.2 Headers
servlet能够通过HttpServletResponse的一些方法设置HTTP响应的头信息，这些方法有：
setHeader
addHeader
setHeader方法会把给定的一个name-values放到头信息中，头信息中只能有一个name-values，后面
setHeader会覆盖前面setHeader方法中的内容，一个name可以有多个value。
addHeader方法可以增加一个value到已有的name上，如果name不同就会新建一个name-values
头可以包含一些信息，如日期或数字对象。
以下的一些方法用适当的数据类型设置头信息：
setIntHeader
setDateHeader
addIntHeader
addDateHeader
在响应被发送到客户端之前，头信息是必须被设置的，如果没有设置头信息，servlet引擎将不会发送该
请求到客户端。HTTP1.1规范没有规定必须设置响应的头信息。当程序员没有设置响应体的Content-
Type时，servlet引擎也不需要设置一个默认的类型。
5.3 其他一些方法
HttpServletResonse接口中还有其他的一些方法：
sendRedirect
sendError
sendRedirect方法将设置合适的头和体信息，用于重定向客户端到另一个URL。如果sendRedirect参数
是个相对路径，则在底层servlet引擎中会把这相对路径转换成绝对路径返回给客户端的。
如果相对路径不能被引擎转换成绝对路径就会抛出IllegalArgumentException错误。
sendError方法会把一条错误信息作为头和体信息发送给客户端。
如果在调用sendRedirect或sendError之前设置了头和体信息，再调用sendRedirect或sendError时，之前
的头和体中的数据信息都将没用，不会被发送到客户端。如果使用了缓存，在调用sendRedirect或
sendError时，之前的信息都将被清除。如果在commit之后调用sendRedirect或sendError就会抛出
IllegalStateException错误。
5.4 国际化
当客户端用一特殊的语言（或客户端设置了语言）发出请求时，servlet会设置相应的响应语言信息，
ServletResponse接口中设置响应语言的方法是setLocale。这个方法会设置一个合适的Content-
Language到头信息中。最好是开发者在调用getWriter方法之前调用setLocale方法，确保返回的
PrintWriter已经被设置好了语言信息。如果在调用setLocale之后又调用了setContentType，setLocale中
的内容将被setContentType中的字符集覆盖。
response默认的编码方式是“ISO-8859-1”。
5.5 response对象的关闭
当response被关闭时，引擎必须刷新该response缓存中的所有内容到客户端。关闭的顺序是：
1）关闭servlet的service方法
2）response 中setContentLength方法设置的指定数量的信息被写入response
3）调用sendError方法
4）调用sendRedirect方法
5.6 response对象的生命周期
每个response对象仅在servlet的serrvice方法或filter的doFilter的方法中有效。引擎重复使用reponse对
象，是为了降低创建response对象的开销。开发者必须注意response对象在指定范围外可能出现的一些
意外的行为。

1.4与其它技术的比较
与其它服务相比servlet有以下的一些优点
1) 运行速度上比CGI快，因为使用了多线程
2) servlet使用了标准的api，可被许多web服务支持
3) 与系统无关性，一次编译多次使用
                                                                    第二章
servlet接口是servlet api核心部分，所有的servlet都是直接或间接的实现了这些接口。两个最重
要的servlet api 接口是GenericServlete 和 HttpServlet，更多的开发者都继承HttpServlet去实现
他们的servlet
2.1 Request 包含的方法
一个基本的servlet接口应该定义一个方法包含客户端的信息，每次servlet引擎把一个request发
送到一个servlet事例，这个方法都要被调用。
对于并发的请求，web应用需要设计者设计的servlet引擎能分配多个线程执行这个方法。
2.1.1 HTTP 请求处理的方法
HttpServlet是实现了Servlet接口的抽象类，增加了一些新的方法，这些方法在处理HTTP请求时
会被service方法自动调用，这些方法是：
doGet 接受 HTTP 的GET请求
doPost 接受 HTTP 的POST请求
doPut 接受 HTTP的PUT请求
doDelete 接受 HTTP的DELETE请求
doHead 接受 接受 HTTP的HEAD请求
doOptions 接受 HTTP的OPTIONS请求
doTrace 接受 HTTP的TRACE请求
一个开发者只会涉及到doGet和doPost方法，其它的方法是为非常熟悉HTTP的设计师准备的

* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/

public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String uri = request.getRequestURI();
out.println(ServletUtilities.headWithTitle("Test Servlet") +
"<BODY BGCOLOR=\"#FDF5E6\">\n" +
"

URI: " + uri + "

URI: <%= request.getRequestURI() %>

* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/

public class SorryServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String title = "Invoker Servlet Disabled.";
out.println(ServletUtilities.headWithTitle(title) +
"<BODY BGCOLOR=\"#FDF5E6\">\n" +
"

" + title + "

* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/

public class InitServlet extends HttpServlet {
private String firstName, emailAddress;

public void init() {
ServletConfig config = getServletConfig();
firstName = config.getInitParameter("firstName");
emailAddress = config.getInitParameter("emailAddress");
}

public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String uri = request.getRequestURI();
out.println(ServletUtilities.headWithTitle("Init Servlet") +
"<BODY BGCOLOR=\"#FDF5E6\">\n" +
"

Init Parameters:

\n" +
"
• First name: " + firstName + "\n" +
  "
• Email address: " + emailAddress + "\n" +
  "

Init Parameters:

• First name: <%= firstName %>
  
• Email address: <%= emailAddress %>
  

* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/

public class ReportFilter implements Filter {
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws ServletException, IOException {
HttpServletRequest req = (HttpServletRequest)request;
System.out.println(req.getRemoteHost() +
" tried to access " +
req.getRequestURL() +
" on " + new Date() + ".");
chain.doFilter(request,response);
}

public void init(FilterConfig config)
throws ServletException {
}

public void destroy() {}
}

一旦建立了一个过滤器，可以在web.xml中利用filter元素以及filter-name（任意名称）、file-class（完全限定的类名）和（可选的）init-params子元素声明它。请注意，元素在web.xml的web-app元素中出现的次序不是任意的；允许服务器（但不是必需的）强制所需的次序，并且实际中有些服务器也是这样做的。但这里要注意，所有filter元素必须出现在任意filter-mapping元素之前， filter-mapping元素又必须出现在所有servlet或servlet-mapping元素之前。
例如，给定上述的ReportFilter类，可在web.xml中作出下面的filter声明。它把名称Reporter与实际的类ReportFilter（位于moreservlets程序包中）相关联。
<filter>
<filter-name>Reporter</filter-name>
<filter-class>moresevlets.ReportFilter</filter-class>
</filter>
一旦命名了一个过滤器，可利用filter-mapping元素把它与一个或多个servlet或JSP页面相关联。关于此项工作有两种选择。
首先，可使用filter-name和servlet-name子元素把此过滤器与一个特定的servlet名（此servlet名必须稍后在相同的 web.xml文件中使用servlet元素声明）关联。例如，下面的程序片断指示系统只要利用一个定制的URL访问名为 SomeServletName 的servlet或JSP页面，就运行名为Reporter的过滤器。
<filter-mapping>
<filter-name>Reporter</filter-name>
<servlet-name>SomeServletName</servlet-name>
</filter-mapping>
其次，可利用filter-name和url-pattern子元素将过滤器与一组servlet、JSP页面或静态内容相关联。例如，相面的程序片段指示系统只要访问Web应用中的任意URL，就运行名为Reporter的过滤器。
<filter-mapping>
<filter-name>Reporter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
例如，程序清单5-12给出了将ReportFilter过滤器与名为PageName的servlet相关联的web.xml文件的一部分。名字 PageName依次又与一个名为TestPage.jsp的JSP页面以及以模式http: //host/webAppPrefix/UrlTest2/ 开头的URL相关联。TestPage.jsp的源代码已经JSP页面命名的谈论在前面的3节"分配名称和定制的URL"中给出。事实上，程序清单5- 12中的servlet和servlet-name项从该节原封不动地拿过来的。给定这些web.xml项，可看到下面的标准输出形式的调试报告（换行是为了容易阅读）。
audit.irs.gov tried to access
http://mycompany.com/deployDemo/UrlTest2/business/tax-plan.html
on Tue Dec 25 13:12:29 EDT 2001.

程序清单5-12 Web.xml（说明filter用法的摘录）
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
<filter>
<filter-name>Reporter</filter-name>
<filter-class>moresevlets.ReportFilter</filter-class>
</filter>
<!-- ... -->
<filter-mapping>
<filter-name>Reporter</filter-name>
<servlet-name>PageName</servlet-name>
</filter-mapping>
<!-- ... -->
<servlet>
<servlet-name>PageName</servlet-name>
<jsp-file>/RealPage.jsp</jsp-file>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name> PageName </servlet-name>
<url-pattern>/UrlTest2/*</url-pattern>
</servlet-mapping>
<!-- ... -->
</web-app>


7 指定欢迎页

假如用户提供了一个像http: //host/webAppPrefix/directoryName/ 这样的包含一个目录名但没有包含文件名的 URL，会发生什么事情呢？用户能得到一个目录表？一个错误？还是标准文件的内容？如果得到标准文件内容，是 index.html、 index.jsp、default.html、default.htm或别的什么东西呢？
Welcome-file-list 元素及其辅助的 welcome-file元素解决了这个模糊的问题。例如，下面的web.xml项指出，如果一个URL给出一个目录名但未给出文件名，服务器应该首先试用index.jsp，然后再试用index.html。如果两者都没有找到，则结果有赖于所用的服务器（如一个目录列表）。
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
虽然许多服务器缺省遵循这种行为，但不一定必须这样。因此，明确地使用welcom-file-list保证可移植性是一种良好的习惯。

8 指定处理错误的页面

现在我了解到，你在开发servlet和JSP页面时从不会犯错误，而且你的所有页面是那样的清晰，一般的程序员都不会被它们的搞糊涂。但是，是人总会犯错误的，用户可能会提供不合规定的参数，使用不正确的URL或者不能提供必需的表单字段值。除此之外，其它开发人员可能不那么细心，他们应该有些工具来克服自己的不足。
error-page元素就是用来克服这些问题的。它有两个可能的子元素，分别是：error-code和exception- type。第一个子元素error-code指出在给定的HTTP错误代码出现时使用的URL。第二个子元素excpetion-type指出在出现某个给定的Java异常但未捕捉到时使用的URL。error-code和exception-type都利用location元素指出相应的URL。此 URL必须以/开始。location所指出的位置处的页面可通过查找HttpServletRequest对象的两个专门的属性来访问关于错误的信息，这两个属性分别是：javax.servlet.error.status_code和javax.servlet.error.message。
可回忆一下，在web.xml内以正确的次序声明web-app的子元素很重要。这里只要记住，error-page出现在web.xml文件的末尾附近，servlet、servlet-name和welcome-file-list之后即可。

8.1 error-code元素
为了更好地了解error-code元素的值，可考虑一下如果不正确地输入文件名，大多数站点会作出什么反映。这样做一般会出现一个404错误信息，它表示不能找到该文件，但几乎没提供更多有用的信息。另一方面，可以试一下在www.microsoft.com、www.ibm.com 处或者特别是在 www.bea.com 处输出未知的文件名。这是会得出有用的消息，这些消息提供可选择的位置，以便查找感兴趣的页面。提供这样有用的错误页面对于 Web应用来说是很有价值得。事实上rm-error-page子元素）。由form-login-page给出的HTML表单必须具有一个 j_security_check的 ACTION属性、一个名为j_username的用户名文本字段以及一个名为j_password的口令字段。
例如，程序清单5-19指示服务器使用基于表单的验证。Web应用的顶层目录中的一个名为login.jsp的页面将收集用户名和口令，并且失败的登陆将由相同目录中名为login-error.jsp的页面报告。

程序清单5-19 web.xml（说明login-config的摘录）
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
<!-- ... -->
<security-constraint> ... </security-constraint>
<login-config>
<auth-method> FORM </auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login-error.jsp</form-error-page>
</form-login-config>
</login-config>
<!-- ... -->
</web-app>


9.2 限制对Web资源的访问
现在，可以指示服务器使用何种验证方法了。"了不起，"你说道，"除非我能指定一个来收到保护的 URL，否则没有多大用处。"没错。指出这些URL并说明他们应该得到何种保护正是security-constriaint元素的用途。此元素在 web.xml中应该出现在login-config的紧前面。它包含是个可能的子元素，分别是：web-resource-collection、 auth-constraint、user-data- constraint和display-name。下面各小节对它们进行介绍。
l web-resource-collection
此元素确定应该保护的资源。所有security-constraint元素都必须包含至少一个web-resource-collection项。此元素由一个给出任意标识名称的web-resource-name元素、一个确定应该保护的URL的url-pattern元素、一个指出此保护所适用的 HTTP命令（GET、POST等，缺省为所有方法）的http-method元素和一个提供资料的可选description元素组成。例如，下面的 Web-resource-collection项（在security-constratint元素内）指出Web应用的proprietary目录中所有文档应该受到保护。
<security-constraint>
<web-resource-coolection>
<web-resource-name>Proprietary</web-resource-name>
<url-pattern>/propritary/*</url-pattern>
</web-resource-coolection>
<!-- ... -->
</security-constraint>
重要的是应该注意到，url-pattern仅适用于直接访问这些资源的客户机。特别是，它不适合于通过MVC体系结构利用 RequestDispatcher来访问的页面，或者不适合于利用类似jsp:forward的手段来访问的页面。这种不匀称如果利用得当的话很有好处。例如，servlet可利用MVC体系结构查找数据，把它放到bean中，发送请求到从bean中提取数据的JSP页面并显示它。我们希望保证决不直接访问受保护的JSP页面，而只是通过建立该页面将使用的bean的servlet来访问它。url-pattern和auth-contraint元素可通过声明不允许任何用户直接访问JSP页面来提供这种保证。但是，这种不匀称的行为可能让开发人员放松警惕，使他们偶然对应受保护的资源提供不受限制的访问。
l auth-constraint
尽管web-resource-collention元素质出了哪些URL应该受到保护，但是auth-constraint元素却指出哪些用户应该具有受保护资源的访问权。此元素应该包含一个或多个标识具有访问权限的用户类别role- name元素，以及包含（可选）一个描述角色的description元素。例如，下面web.xml中的security-constraint元素部门规定只有指定为Administrator或Big Kahuna（或两者）的用户具有指定资源的访问权。
<security-constraint>
<web-resource-coolection> ... </web-resource-coolection>
<auth-constraint>
<role-name>administrator</role-name>
<role-name>kahuna</role-name>
</auth-constraint>
</security-constraint>
重要的是认识到，到此为止，这个过程的可移植部分结束了。服务器怎样确定哪些用户处于任何角色以及它怎样存放用户的口令，完全有赖于具体的系统。
例如，Tomcat使用install_dir/conf/tomcat-users.xml将用户名与角色名和口令相关联，正如下面例子中所示，它指出用户joe（口令bigshot）和jane（口令enaj）属于administrator和kahuna角色。
<tomcat-users>
<user name="joe" password="bigshot" roles="administrator,kahuna" />
<user name="jane" password="enaj" roles="kahuna" />
</tomcat-users>
l user-data-constraint
这个可选的元素指出在访问相关资源时使用任何传输层保护。它必须包含一个transport-guarantee子元素（合法值为NONE、 INTEGRAL或CONFIDENTIAL），并且可选地包含一个description元素。transport-guarantee为NONE值将对所用的通讯协议不加限制。INTEGRAL值表示数据必须以一种防止截取它的人阅读它的方式传送。虽然原理上（并且在未来的HTTP版本中），在 INTEGRAL和CONFIDENTIAL之间可能会有差别，但在当前实践中，他们都只是简单地要求用SSL。例如，下面指示服务器只允许对相关资源做 HTTPS连接：
<security-constraint>
<!-- ... -->
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
l display-name
security-constraint的这个很少使用的子元素给予可能由GUI工具使用的安全约束项一个名称。
9.3 分配角色名
迄今为止，讨论已经集中到完全由容器（服务器）处理的安全问题之上了。但servlet以及JSP页面也能够处理它们自己的安全问题。
例如，容器可能允许用户从bigwig或bigcheese角色访问一个显示主管人员额外紧贴的页面，但只允许bigwig用户修改此页面的参数。完成这种更细致的控制的一种常见方法是调用HttpServletRequset的isUserInRole方法，并据此修改访问。
Servlet的 security-role-ref子元素提供出现在服务器专用口令文件中的安全角色名的一个别名。例如，假如编写了一个调用 request.isUserInRole（"boss"）的servlet，但后来该servlet被用在了一个其口令文件调用角色manager而不是boss的服务器中。下面的程序段使该servlet能够使用这两个名称中的任何一个。
<servlet>
<!-- ... -->
<security-role-ref>
<role-name>boss</role-name> <!-- New alias -->
<role-link>manager</role-link> <!-- Real name -->
</security-role-ref>
</servlet>
也可以在web-app内利用security-role元素提供将出现在role-name元素中的所有安全角色的一个全局列表。分别地生命角色使高级IDE容易处理安全信息。

10 控制会话超时

如果某个会话在一定的时间内未被访问，服务器可把它扔掉以节约内存。可利用HttpSession的setMaxInactiveInterval方法直接设置个别会话对象的超时值。如果不采用这种方法，则缺省的超时值由具体的服务器决定。但可利用session-config和session- timeout元素来给出一个适用于所有服务器的明确的超时值。超时值的单位为分钟，因此，下面的例子设置缺省会话超时值为三个小时（180分钟）。
<session-config>
<session-timeout>180</session-timeout>
</session-config>

11 Web应用的文档化

越来越多的开发环境开始提供servlet和JSP的直接支持。例子有Borland Jbuilder Enterprise Edition、 Macromedia UltraDev、Allaire JRun Studio（写此文时，已被Macromedia收购）以及 IBM VisuaAge for Java等。
大量的web.xml元素不仅是为服务器设计的，而且还是为可视开发环境设计的。它们包括icon、display-name和discription等。
可回忆一下，在web.xml内以适当地次序声明web-app子元素很重要。不过，这里只要记住icon、display-name和description是web.xml的web-app元素内的前三个合法元素即可。
l icon
icon元素指出GUI工具可用来代表Web应用的一个和两个图像文件。可利用small-icon元素指定一幅16 x 16的GIF或JPEG图像，用large-icon元素指定一幅32 x 32的图像。下面举一个例子：
<icon>
<small-icon>/images/small-book.gif</small-icon>
<large-icon>/images/tome.jpg</large-icon>
</icon>
l display-name
display-name元素提供GUI工具可能会用来标记此Web应用的一个名称。下面是个例子。
<display-name>Rare Books</display-name>
l description
description元素提供解释性文本，如下所示：
<description>
This Web application represents the store developed for
rare-books.com, an online bookstore specializing in rare
and limited-edition books.
</description>

12 关联文件与MIME类型

服务器一般都具有一种让Web站点管理员将文件扩展名与媒体相关联的方法。例如，将会自动给予名为mom.jpg的文件一个image/jpeg的 MIME 类型。但是，假如你的Web应用具有几个不寻常的文件，你希望保证它们在发送到客户机时分配为某种MIME类型。mime-mapping元素（具有 extension和mime-type子元素）可提供这种保证。例如，下面的代码指示服务器将application/x-fubar的 MIME类型分配给所有以.foo结尾的文件。
<mime-mapping>
<extension>foo</extension>
<mime-type>application/x-fubar</mime-type>
</mime-mapping>
或许，你的Web应用希望重载（override）标准的映射。例如，下面的代码将告诉服务器在发送到客户机时指定.ps文件作为纯文本（text/plain）而不是作为PostScript（application/postscript）。
<mime-mapping>
<extension>ps</extension>
<mime-type>application/postscript</mime-type>
</mime-mapping>


13 定位TLD

JSP taglib 元素具有一个必要的uri属性，它给出一个TLD（Tag Library Descriptor）文件相对于Web应用的根的位置。TLD文件的实际名称在发布新的标签库版本时可能会改变，但我们希望避免更改所有现有JSP页面。此外，可能还希望使用保持taglib元素的简练性的一个简短的uri。这就是部署描述符文件的taglib元素派用场的所在了。Taglib包含两个子元素：taglib-uri和taglib-location。 taglib-uri元素应该与用于JSP taglib元素的uri属性的东西相匹配。Taglib-location元素给出TLD文件的实际位置。例如，假如你将文件chart-tags- 1.3beta.tld放在WebApp/WEB-INF/tlds中。现在，假如web.xml在web- app元素内包含下列内容。
<taglib>
<taglib-uri>/charts.tld</taglib-uri>
<taglib-location>
/WEB-INF/tlds/chart-tags-1.3beta.tld
</taglib-location>
</taglib>
给出这个说明后，JSP页面可通过下面的简化形式使用标签库。
<%@ taglib uri="/charts.tld" prefix="somePrefix" %>

14 指定应用事件监听程序

应用事件监听器程序是建立或修改servlet环境或会话对象时通知的类。它们是servlet规范的版本2.3中的新内容。这里只简单地说明用来向Web应用注册一个监听程序的web.xml的用法。
注册一个监听程序涉及在web.xml的web-app元素内放置一个listener元素。在listener元素内，listener-class元素列出监听程序的完整的限定类名，如下所示：
<listener>
<listener-class>package.ListenerClass</listener-class>
</listener>
虽然listener元素的结构很简单，但请不要忘记，必须正确地给出web-app元素内的子元素的次序。listener元素位于所有的 servlet 元素之前以及所有filter-mapping元素之后。此外，因为应用生存期监听程序是serlvet规范的2.3版本中的新内容，所以必须使用 web.xml DTD的2.3版本，而不是2.2版本。
例如，程序清单5-20给出一个名为ContextReporter的简单的监听程序，只要Web应用的Servlet-Context建立（如装载Web应用）或消除（如服务器关闭）时，它就在标准输出上显示一条消息。程序清单5-21给出此监听程序注册所需要的web.xml文件的一部分。

程序清单5-20 ContextReporterjava
package moreservlets;

import javax.servlet.*;
import java.util.*;

/** Simple listener that prints a report on the standard output
* when the ServletContext is created or destroyed.
*

* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/

public class ContextReporter implements ServletContextListener {
public void contextInitialized(ServletContextEvent event) {
System.out.println("Context created on " +
new Date() + ".");
}

public void contextDestroyed(ServletContextEvent event) {
System.out.println("Context destroyed on " +
new Date() + ".");
}
}


程序清单5-21 web.xml（声明一个监听程序的摘录）
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
<!-- ... -->
<filter-mapping> … </filter-mapping>
<listener>
<listener-class>package.ListenerClass</listener-class>
</listener>
<servlet> ... </servlet>
<!-- ... -->
</web-app>


15 J2EE元素

本节描述用作J2EE环境组成部分的Web应用的web.xml元素。这里将提供一个简明的介绍，详细内容可以参阅http: //java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf的 Java 2 Plantform Enterprise Edition版本1.3规范的第5章。
l distributable
distributable 元素指出，Web应用是以这样的方式编程的：即，支持集群的服务器可安全地在多个服务器上分布Web应用。例如，一个可分布的应用必须只使用 Serializable对象作为其HttpSession对象的属性，而且必须避免用实例变量（字段）来实现持续性。distributable元素直接出现在discription元素之后，并且不包含子元素或数据，它只是一个如下的标志。
<distributable />
l resource-env-ref
resource -env-ref元素声明一个与某个资源有关的管理对象。此元素由一个可选的description元素、一个resource-env-ref- name元素（一个相对于java:comp/env环境的JNDI名）以及一个resource-env-type元素（指定资源类型的完全限定的类），如下所示：
<resource-env-ref>
<resource-env-ref-name>
jms/StockQueue
</resource-env-ref-name>
<resource-env-ref-type>
javax.jms.Queue
</resource-env-ref-type>
</resource-env-ref>
l env-entry
env -entry元素声明Web应用的环境项。它由一个可选的description元素、一个env-entry-name元素（一个相对于java: comp/env环境JNDI名）、一个env-entry-value元素（项值）以及一个env-entry-type元素（java.lang程序包中一个类型的完全限定类名，java.lang.Boolean、java.lang.String等）组成。下面是一个例子：
<env-entry>
<env-entry-name>minAmout</env-entry-name>
<env-entry-value>100.00</env-entry-value>
<env-entry-type>minAmout</env-entry-type>
</env-entry>
l ejb-ref
ejb -ref元素声明对一个EJB的主目录的应用。它由一个可选的description元素、一个ejb-ref-name元素（相对于java: comp/env的EJB应用）、一个ejb-ref-type元素（bean的类型，Entity或Session）、一个home元素（bean的主目录接口的完全限定名）、一个remote元素（bean的远程接口的完全限定名）以及一个可选的ejb-link元素（当前bean链接的另一个 bean的名称）组成。
l ejb-local-ref
ejb-local-ref元素声明一个EJB的本地主目录的引用。除了用local-home代替home外，此元素具有与ejb-ref元素相同的属性并以相同的方式使用