web.xml解析详解：核心概念与配置

需积分: 3 17 浏览量更新于2024-07-31 1 收藏 1.07MB PDF 举报

"web.xml 详细解析四合一.pdf 是一份关于JavaEE Web应用配置核心文件web.xml的深入解析资料，适合需要理解web.xml文件结构和功能的开发者学习。该文件由PHLIPS在2010年9月18日发布，提供了关于web.xml的详细解析，包括其基本构成、元素定义和顺序要求。" 在JavaEE中，`web.xml`文件是Web应用的部署描述符，它包含了关于Servlet容器如何运行和管理Web应用的关键配置信息。以下是`web.xml`的一些关键知识点： 1. XML头部和根元素： - XML头：文件开始时需包含一个XML声明，用于指定XML版本和字符编码。 - DOCTYPE声明：紧随XML头后，用于指明servlet规范的版本和DTD，确保解析遵循正确的语法规则。 - `web-app`元素：作为部署描述符的根元素，它包含所有其他配置元素。 2. 大小写和顺序敏感性： - XML元素大小写敏感，如`web-app`而非`WEB-APP`。 - 元素顺序至关重要，例如XML头、DOCTYPE声明和`web-app`元素的顺序不能错乱，否则可能导致服务器拒绝解析或降低应用的可移植性。 3. 元素顺序和可选性： - `web-app`内部元素的顺序有特定要求，如`servlet`必须在`servlet-mapping`之前。 - 尽管所有元素都是可选的，但一旦使用，就必须按照规定的顺序排列，否则可能影响服务器处理。 4. 主要配置元素： - `icon`：定义Web应用在IDE或GUI工具中的图标。 - `display-name`：提供Web应用的显示名称，便于识别。 - `description`：提供描述性文本，解释应用的功能或用途。 - `context-param`：声明应用级别的初始化参数，可在整个应用中使用。 - `filter`：定义一个过滤器，将其与实现了`javax.servlet.Filter`接口的类关联。 - `filter-mapping`：将过滤器映射到一个或多个Servlet或JSP页面，控制过滤器的执行范围。 - `listener`：配置Servlet监听器，这些监听器会在Servlet生命周期的特定事件上执行。理解并熟练掌握`web.xml`的配置是开发和管理JavaEE Web应用的基础，通过合理的配置，开发者可以实现如安全控制、URL路由、性能优化等高级功能。这份详细解析四合一的文档能帮助开发者深入理解`web.xml`的结构和配置技巧，提高Web应用的管理和维护能力。

例如，给定上述的 ReportFilter 类，可在 web.xml 中作出下面的 filter 声明。它把名称 Reporter 与实

际的类 ReportFilter（位于 moreservlets 程序包中）相关联。

<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-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-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>

</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 能够使用这两个

名称中的任何一个。

<security-role-ref>

<role-name>boss</role-name>

<role-link>manager</role-link>

</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>

剩余96页未读，继续阅读

liyang199133

粉丝: 1

web.xml解析详解：核心概念与配置

Spring MVC web.xml配置深度解析与实战指南

web.xml配置解析：servlet、filter、listener加载顺序详解

解决web.xml无法解析绝对URI的简单有效方法

web.xml详细解析四合一.docx

深入解析Tomcat的web.xml与server.xml配置

web.xml加载顺序解析：从context-param到servlet

web.xml详解：核心配置与解析

深入解析web.xml配置与元素详解

Servlet2.3配置指南：深入解析web.xml

JavaWeb开发：web.xml配置教程与常见错误解析

最新资源