查看源码。得知。

作者：冉翔

第一部分 持久层

第一章           面向应用的持久层设计

现今的应用系统设计中，MVC（Model-View-Control）作为主流系统架构模式之一，贯穿了整个设计流程。MVC中的M，也就是所谓的Model，则可以说是与业务逻辑和数据逻辑关联最为紧密地部分。而持久层作为Model层面中的主要组成，其设计的优劣必对系统的整体表现产生至关重要的影响。

1.1 持久层概述

持久（Persistence）。简单来讲，也就是把数据保存到可掉电式存储设备中供之后使用。

所谓“持久层”，也就是在系统逻辑层面上，专注于实现数据持久化的一个相对独立的领域（Domain）。

1.2 持久层设计

1.2.1        持久层设计与解耦合

1.2.1.1    何谓耦合，何谓解耦合

何谓耦合？通俗地讲，就是事物之间的相互关联关系。

何谓解耦合？即采用一些手段降低关联的紧密程度。

1.2.1.2    解耦合思想的自然演讲

1.2.1.3    解耦合设计的目标

·应用层解耦合――应用逻辑与数据逻辑相分离

·资源曾解耦合――逻辑结构与物力结构相分离

1.2.1.4    持久层解耦合与DAO模式

DAO（Data Access Object）模式实际上是两个模式的组合。即Data Accessor模式与Active Domain Object模式，其中Data Accessor模式实现了数据访问和业务逻辑的分离，而Active Domain Object模式实现了业务数据的对象化封装，一般我们将这两个模式组合使用。

DAO模式通过对业务层提供数据抽象层接口，实现了以下目标：

1.         数据存储逻辑的分离

2.         数据访问底层实现的分离

3.         资源管理和调度的分离

4.         数据抽象

Data Accessor：即将数据访问的实现机制加以封装，与数据的使用代码相分离，从外部来看，Data Accessor提供了黑盒式的数据存取接口。

Domain Object：则提供了对面向领域内对象的封装。

Data Accessor Object（DAO）= Data + Accessor + domain Object

所谓Domain Object，简单来讲就是对领域内（Domain）设计的各个数据对象，反映到代码，就是一个拥有相关属性的getter，setter方法的Java Class（Java Bean）。

1.2.1.5    DAO模式的进一步改良

· Factory模式的引入

· Proxy模式的引入

1.2.2        持久层设计与资源管理模式

1.2.2.1    Connection Pool

数据库连接池的基本原理是在内部对象池中维护一定数量的数据库连接，并对外暴露数据库连接获取和返回方法。

数据库连接池技术带来下面的优势：

1．  资源重用

2．  更快的系统响应速度

3．  新的资源分配手段

4．  统一的连接管理，避免数据库连接泄漏

·Decorator模式

  Decorator模式的主要目的是利用一个对象，透明地为另一个对象添加新的功能。

  简单来讲，就是通过一个Decorator对原有对象进行封装，同时实现与原有对象相同的接口，从而得到一个基于原有对象的，对既有接口的增强性实现。

·Dynamic Proxy模式

  严格来讲，Dynamic Proxy本身并非一种模式，只能算是Proxy模式的一种动态实现方式。

·他山之石

    ·Apache Jakarta Commons DBCP

    ·Proxool

1.2.2.2    Statement Pool

1.3 持久层设计与ORM

1.3.1        ORM概述

   ORM – Object/Relation Mapper：对象－关系型数据映射组件。

  O/R Mapping描述的是一种设计思想或者实现机制，而O/R Mapper一般指根据O/R原理设计的持久化框架，其中包含了除O/R本身之外的更多内容，如SQL自生成，事务管理，Cache管理等。

1.3.2        持久层实现类型

· 混杂模式

   这种模式的优点在于开发的迅速便捷。对于原型系统或者小型应用而言显得别具意义。但基于这种模式开发的系统，其维护性和扩展性较差，对象属性，数据库结构的变动都将直接导致业务逻辑代码的修改。

· 基于Data Class的持久层实现模式

   DAO模式就是这种模式的一种典型实现。

   在这种模式中，我们实现了业务逻辑与此曾数据结构之间的分离。Data Class作为一个相对独立的逻辑层次。较为清晰的体现了所谓持久层的概念。底层关系数据的结构变化，可以较好地屏蔽在数据类这个层次。从而避免对上层的业务逻辑造成影响。

   缺点：随着设计层次的增多，编码量的增加相当可观。相对地一种混杂模式而言，系统结构上得到较大提升的同时，项目设计和开发成本也相应增高。

· 基于现有持久层框架的实现模式

   这种模式是第二种模式的眼神。Data Class所包含的Data Accessor和Domain Class数量并没有减少。

   只是把其中最为繁琐的工作――基于JDBC的OR映射工作，交给第三方组建完成。

   Data Accessor中的繁琐编码工作因此得到了空前简化，而与此同时，伴随持久层框架而来的辅助工具也大大减轻了Domain Class的编码负担。

1.4 持久层框架概述

一个成熟的持久化框架能为我们作些什么？

· 减少乏味的代码

· 更加面向对象的设计

· 更好的性能

· 更好的移植性

1.5 主流持久层框架综述

· Apache OJB

· Hibernate

· iBatis

· TopLink（是Oracle的商业产品）

1,先在一个Action中，调用saveToken(HttpServletRequest request)方法。然后转向带有表单的JSP页面。

2，在JSP页面提交表单给一个Action，再这个Action中进行是否为重复提交的判断。

              if (isTokenValid(request, true)) {

                     // 未重复提交时，正确的时候应该做的事情

                  return mapping.findForward("success");

              } else {

            // 重复提交时，需要做的事情

                  saveToken(request);

                  return mapping.findForward("error");

              }

Struts Token 机制：

1，  由第一个Action调用saveToken(HttpServletRequest request)，这个方法内部实现如下：

    protected void saveToken(HttpServletRequest request) {

        token.saveToken(request);

}

        token.saveToken(request);

       这个方法的实现如下：

    public synchronized void saveToken(HttpServletRequest request) {

 

        HttpSession session = request.getSession();

        String token = generateToken(request);

        if (token != null) {

            session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);

        }

}

这个方法调用generateToken方法实现如下：

    public synchronized void saveToken(HttpServletRequest request) {

 

        HttpSession session = request.getSession();

        String token = generateToken(request);

        if (token != null) {

            session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);

        }

}

generateToken完毕后，将得到的唯一值setAttribute到session中。

            session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);

Globals.TRANSACTION_TOKEN_KEY的值是：” org.apache.struts.action.TOKEN”

然后跳转到JSP页面。

2，  JSP页面的Struts自定义标签 <html:form>的标签类：org.apache.struts.taglib.html. FormTag

这个类的doStartTag()方法会调用本类的renderToken()方法。

    protected String renderToken() {

        StringBuffer results = new StringBuffer();

        HttpSession session = pageContext.getSession();

 

        if (session != null) {

            String token =

                (String) session.getAttribute(Globals.TRANSACTION_TOKEN_KEY);

                

            if (token != null) {

                results.append("<input type=\"hidden\" name=\"");

                results.append(Constants.TOKEN_KEY);

                results.append("\" value=\"");

                results.append(token);

                if (this.isXhtml()) {

                    results.append("\" />");

                } else {

                    results.append("\">");

                }

            }

        }

 

        return results.toString();

}

这样子会生成类似于

<input type="hidden" name="org.apache.struts.taglib.html.TOKEN" 
         value="6aa35341f25184fd996c4c918255c3ae">

的隐藏标签。

然后提交到一个Action中，在Action中用isTokenValid()方法进行比较session中” org.apache.struts.action.TOKEN”的这个key所对应的值和提交来的request中的” org.apache.struts.action.TOKEN”的这个value是否一致。

如果为true，那么证明可以提交。如果为false，证明已经重复，不允许提交。

一个好的软件框架应该具备可扩展特性。在Struts框架中提供了许多可扩展之处，不放将其称为可扩展点（Extension Point）。以下是Struts的扩展点：

· 一般性扩展点：Struts插件（PlugIn）、扩展Struts配置类。

· 控制器的扩展点：扩展ActionServlet类、RequestProcessor类和Action类。

· 视图的扩展点：扩展Struts客户化标签。

· 模型的扩展点：扩展SessionContainer类和ApplicationContainer类。

1.   Struts插件（PlugIn）

Struts1.1框架提供了动态插入和加载组件的功能，这种组件被成为Struts插件。Struts插件实际上就是一个Java类，它在Struts应用启动时被初始化，在应用关闭时被销毁。任何作为插件的Java类都应该实现org.apache.struts.action.PlugIn接口。PlugIn接口包括两个方法：

public interface PlugIn {

/**

* Notification that the specified application module is being started.

*/

public void init(ActionServlet servlet, ApplicationConfig config)

throws ServletException;

       /**

* Notification that the application module is being shut down.

*/

public void destroy();

}

一个Struts应用可以包含一个或多个插件。在Struts应用启动时，Struts框架调用每个插件类的init()方法进行初始化。在插件的初始化阶段，可以完成一些初始化操作，如建立数据库连接，或者和远程系统的连接等。

当应用被关闭时，Struts框架就会调用每个插件类的destroy()方法，destroy()方法可以用来完成释放资源的人物，如关闭数据库连接或远程系统连接等。

除了创建插件类外，还需要在Struts配置文件中配置插件，Struts框架在启动时将根据相关的配置信息来初始化插件。与插件对应的配置元素为<plug-in>。

根据Struts配置文件的DTD定义，在Struts配置文件中，<plug-in>元素必需位于其他配置元素的后面。此外，如果在配置文件中配置了多个插件，Struts框架将按照它们在配置文件中的先后顺序来一次初始化他们。

2.   扩展Struts的配置类

在Struts应用启动时，Struts配置文件中的所有信息都会被读到内存中，这些信息存放在org.apache.struts.config包的相应配置类的实例中。

多数配置元素都由一个className属性，这个属性用来设置和配置元素对应的配置类。每个配置元素都有默认配置类，Struts框架允许对这些莫尔那配置类进行扩展。

3.   控制器扩展点

Struts框架在控制器中提供了许多可扩展之处，允许扩展ActionServlet、RequestProcessor和Action类，来实现各种客户化功能。

3.1 扩展ActionServlet类

在Struts1.1以前的版本中，Struts应用通常都需要扩展ActionServlet类，来实现各种定制的控制功能。在Struts1.1中，扩展ActionServlet类不再是必需的。不过在某些情况下，根据实际情况需要，可不妨扩展ActionServlet类。

当Struts应用启动时会加载ActionServlet类并调用它的init()方法，来对Struts框架进行初始化。如果需要修改Struts框架的初始化行为，可以创建一个org.apache.struts.action.ActionServlet类的子类，然后覆盖它的init()方法。

接下来，应该在web.xml文件中对自定义的ActionServlet进行配置。

在Struts1.1中，预处理HTTP请求的具体操作由RequestProcessor类来完成。因此，如果需要对预处理HTTP请求的方式进行客户化，可以扩展RequestProcessor类。

3.2 扩展RequestProcessor类

如果扩展了RequestProcessor类，应该在Struts配置文件中通过<controller>元素对自定义的RequestProcessor类进行配置。

<controller>元素的processorClass属性用来指定使用的RequestProcessor类。Struts框架在启动时会创建这个RequestProcessor类的实例，并利用它来处理所有的HTTP请求。由于每个子应用模块都有各自的配置文件，因此可以为每个子应用模块配置不同的RequestProcessor类。

RequestProcessor类的一个扩展点为processPreprocess()方法。在RequestProcessor基类中，该方法不执行任何操作，志军诶返回true。

RequestProcessor类在process()方法中处理请求，Process()方法在调用Action的execute()方法之前，就会调用processPreprocess()方法，如果processPreprocess()方法返回true，则表示继续按正常的流程处理请求。

在自定义的RequestProcessor类中，可以覆盖processPreprocess()方法来执行特定的逻辑。如果在某些条件下希望终止处理请求，只需让processPreprocess()方法false即可。在这种情况下，仍需要以编程的方式来决定如何转发或重定向请求。

Servlet 2.3 API提供了Servlet过滤器，它可以实现和processPreprocess()方法相同的功能。Servlet过滤器也可以用来执行客户化的预处理请求操作，Web容器先调用Servlet过滤器，再把请求转发给Struts控制器。

与扩展RequestProcessor类相比，通过Servlet过滤器来预处理请求有两大弱点：

3.3 扩展Action类

Struts框架的Action类是最频繁的扩展点。对于具体的Struts应用，可以先为应用创建一个扩展Struts Action类的Action基类，在这个Action基类中定义应用中所有Action的一些公共逻辑，它可以作为其他Action的父类。这种处理方式可以提高代码的可重用性，减少代码的重复。

4.   扩展视图组件

一般说来，没有必要扩展视图组件，因为不同的应用有不同的外观和界面，一个应用的JSP页面不大可能适用于另一个不同的应用。不过，可以扩展Struts客户化标签，因为标签处理器为常规的Java类，可以通过定义子类的方式来扩展它们，这些扩展后的客户化标签能够被不同的应用重用。

Struts HTML标签库中的标签对视图内容的影响最大。因此可以扩展这些标签来创建客户化的应用外观。当扩展了标签后，应该定义存放这些标签的标签库。尽管可以把自定义的标签加入到标准的Struts标签库中，但是这会使将应用升级到新的Struts版本变得更加麻烦。所以建议定义单独的标签库，来存放和特定应用相关的客户化标签。

一旦为客户华标签库创建了TLD文件，并且在web.xml中注册了标签库，就可以在JSP文件中方便地使用这些标签了。

5.   扩展模型组件

Struts框架本身没有在模型层提供现成的模型组件，因此扩展模型组件不属于Struts技术。

6.   小结

本篇文档归纳了Struts框架的所有可扩展点。Struts框架的可扩展性使开发者可以方便地定制客户化功能，提高应用的灵活性和多各种需求的可适应性。然而，实现更多的功能使要花费更大代价的，应该避免滥用Struts的可扩展特性。Struts由核心包加上很多工具包构成。它们已经提供了很多现成的功能。因此不要盲目地扩展Struts框架，在决定编写扩展代码前，务必先确认Struts没有提供现成的您需要的功能。否则，重复的功能会导致应用结构的混乱，将来还得花费额外的经历来清除重复功能。

此外，必需考虑扩展后的框架是否会和将来的新的Struts版本兼容，从Struts 1.0到Struts 1.1就发生了很大的改动。在先有的Struts版本的API中，如果有的类的方法已经声明将要被废弃，应该尽量不要覆盖这些方法，否则，当采用新的Struts版本时，就不得不对应用做相应的升级。

模型代表应用的业务数据和逻辑。Struts框架并没有为设计和创建模型组件提供现成的框架。不过，Struts允许使用其他模型框架来处理应用的业务领域，如EJB(Enterprise JavaBean)和JDO(Java Data Object)，以及常规的JavaBean和ORM(Object-Relation Mapping)。

1 模型在MVC中的地位

模型是应用中最重要的一部分，它包含了业务实体和业务规则，负责访问和更新持久化数据。应该把所有的模型组件放在系统中的同一个位置，这有利于维护数据的完整性，减少数据冗余，提高可重用性。

模型应该和视图以及控制器之间保持独立。在分层的的框架结构中，位于上层的视图和控制器依赖于下层模型的实现，而上层模型不应该依赖于上层的视图和控制器的实现。Struts应用的各个层次之间的依赖关系：

从上到下，依赖关系加强；从下到上，依赖关系减弱。

如果在模型组件中通过Java的import语句引入了视图和控制器组件，这就违反了以上原则。下层组件访问上层组件会使应用的维护、重用和扩展变得困难。

2 模型的概念和类型。

在科学和工程技术领域，模型是一个很有用途的概念，它可以用来模拟一个真实的系统。建立模型最主要的目的是帮助理解、描述或模拟真实世界中目标系统的运转机制。

在软件开发领域，模型用来表示真实世界的实体。在软件开发的不同阶段，需要为目标系统创建不同类型的模型。在分析阶段，需要创建概念模型。在设计阶段，需要创建设计模型。可以采用面向对象建模语言UML来描述模型。

2.1 概念模型

    在建立模型之前，首先要对问题域进行详细的分析，确定用例，接下来就可以根据用例来创建概念模型。概念模型用来模拟问题域中的真实实体。概念模型描述了每个实体的概念和属性，以及实体之间的关系。但在这个阶段并不描述实体的行为。

    创建概念模型的目的是帮助更好地理解问题域，识别系统中的实体，这些实体在设计阶段很有可能变成类。

    概念模型清楚地显示了问题域中的实体。不管是技术人员还是非技术人员都能看得懂概念模型，他们可以很容易地提出概念模型中存在的问题，帮助系统分析人员及早对模型进行修改。在软件设计与开发周期中，模型的变更需求提出得越晚，所耗费的开发成本就越大。

2.2 设计模型

    概念模型是在软件分析阶段创建的，它帮助开发人员对应的需求获得清晰精确的理解。在软件设计阶段，需要在概念模型的基础上创建设计模型。可以用UML类框图，活动图以及状态图来描述设计模型。

    根据UML语言，类直接存在四种关系。

    1 关联(Association)

        关联指的是类之间的引用关系。

    2 依赖(Dependency)

        依赖指的是类之间的访问关系。

    3 累积(Aggregation)

        累积指的是整体与个体之间的关系，可以把累积看作一种强关联关系。

    4 一般化(Generalization)

        一般化指的是类之间的继承元素。

3 业务对象(BO)

业务对象，即Business Object(BO)，是对真实世界的实体的软件抽象。它可以代表业务领域中的人、地点、事物或概念。

   业务对象包括状态和行为。

判断一个类是否可以成为业务对象的一个重要标准，是看这个类是否同时拥有状态和行为。

3.1 业务对象的特征和类型

    如果一个类可以作为业务对象，它应具有以下特征：

    · 包含状态和行为

    · 代表业务领域的人、地点、事物或概念

    · 可以重用

    业务对象可分为三种类型：

    · 实体业务对象

    · 过程业务对象

    · 事件业务对象

     实体业务对象要算是最为人们所熟悉的。实体对象可以代表人、地点、事物或概念。通常，可以把业务领域中的名词，例如客户、订单、商品等作为实体业务对象。在J2EE应用中，这些名词可以作为实体Bean。对于更普通的Web应用，这些名词可以作为包含状态和行为的JavaBean。

     过程业务对象代表应用种的业务过程或流程，它们通常依赖于实体业务对象。可以把业务领域中的动词。例如客户发出订单、登入应用等作为过程业务对象。在J2EE应用中，它们通常作为会话Bean或者消息驱动Bean。在非J2EE应用中，他们可作为常规的JavaBean，具有管理和控制应用的行为。过程业务对象也可以拥有状态，例如在J2EE应用中，会话Bean可分为有状态和无状态两种。

     事件业务对象代表应用中的一些时间（如异常、警告或超时）。这些时间通常由系统中的某种行为处罚。例如，在Java Swing应用中，当客户按下一个按钮，就会有一个事件业务对象产生，以便通知框架调用相关的时间处理器来处理事件。

3.2 业务对象的重要性

    在 应用中使用业务对象有许多好处，最重要的一点就是业务对象提供了通用的术语和概念，不管是技术人员还是非技术人员都可以共享并理解他们。它们可以直观地代 表真实世界中的概念，开发小组的所有成员都能理解他们。如果正对同一个业务领域需要开发出多个应用，那么这些应用可以共享这些业务对象。业务对象的可重用 特性可以提高应用开发速度。减少冗余。

    此外，业务对象可以隐藏实现细节，对外只保露接口。例如，如果业务对象的某个方法需要传入java.util.ArrayList类型的参数，那么应该把参数定义为java.util.List接口类型。这样，假定这个方法的实现发生改变，用LinkedList取代ArrayList来实现原有的功能，这种概念不会对方法调用者造成任何英雄。

    在充分了解到业务对象在应用中的重要性后，接下来需要关心的问题是，这些业务对象的状态从何而来，当应用中指运行时，这些状态被存放到什么地方。这就涉及到了对象的持久化问题。

4 业务对象的持久化

通常，持久化意味着通过手工或其他方式输入到应用中的数据，能够在应用结束运行后依然存在。即使应用运行结束或者计算机关闭后，这些信息依然存在。不管是大、中或、小型的应用，都需要数据的持久化。

4.1 对业务对象进行持久化的作用。

当应用中的业务对象在内存中创建后，它们不可能永远存在。最后，他们要么从内存中清楚，要么被持久化到数据存储库中。内存无法永久保存数据，因此必需对业务对象进行持久化。否则，如果对象没有被持久化，用户在应用运行时发出的订单信息将在应用结束运行后随之小时。

关系型数据库被广泛用来存储数据。关系型数据库中存放的是关系型数据，它是非面向对象的。把业务对象映射到非面向对象的数据库中，存在着阻抗不匹配（impedance mismatch），因此对象由状态和行为组成，而关系型数据库则由表组成，对象之间的各种关系和关系型数据库中表之间的关系并不一一对象。例如对象之间的继承关系就不能直接映射到关系型数据库中。

4.2 数据访问对象（DAO）设计模式

面向对象的开发方法是当今的主流，但是同时不得不使用关系型数据库，在企业级应用开发的环境中，对象－关系的映射（Object-Relation Mapping，简称ORM）是一种耗时的工作。围绕对象－关系的映射和持久化数据的访问，在软件领域中发展起来了一种数据访问对象（Data Access Object，简称DAO）设计模式。

DAO模式提供了访问关系型数据库系统所需的所有操作的接口，其中包括创建数据库、定义表、字段和索引，建立表间的关系，更新和查询数据库等。DAO模式将底层数据访问操作与高层业务逻辑分离开，对上层提供面向对象的数据访问接口。在DAO的实现中，可以采用XML语言来配置对象和关系型数据之间的映射。

对于Java应用，可以直接通过JDBC编程来访问数据库。JDBC可以说是访问持久数据层最原始、最直接的方法。在企业级应用开发中，可以通过JDBC编程，来开发自己的DAO API，把数据库访问操作封装起来，供业务曾同一调用。

如果数据模型非常复杂，那么直接通过JDBC编程来实现持久化框架需要有专业的知识。对于企业应用的开发人员，花费大量时间从头开发自己的持久性框架不是很可行。通常，可以直接采用第三方提供的持久化框架，如ORM软件产品。许多ORM框架都采用DAO设计模式来实现，为模型层提供了访问关系型数据库的API。

4.3 常用的ORM软件

有许多ORM软件可供选择。有些是商业化的，有些是免费的。

       不管是使用商业化产品，还是非商业化产品，都应该确保选用的ORM框架没有“渗透”到应用中，应用的上层组件应该和ORM框架保持独立。有些ORM框架要求在业务对象中印入它们的类和接口，这会带来一个问题，如果日后想改用其他的ORM框架，就必需修改业务对象。

5 小结

这篇文档介绍了模型的实现方法。Struts框架并没有在模型层提供线程可用的组件。模型的实现应该和Struts应用的控制层以及视图层保持独立。

模型采用业务对象来描述状态和行为，为了使业务对象持久化，需要把业务对象映射到关系型数据库。

模型向客户程序提供了业务代理接口，业务代理接口直接访问持久化框架，处理实际的业务逻辑。Struts应用的Action类可以使用这个业务代理接口，而不必直接和持久化框架交互。这种做法有助于削弱上层Web应用和持久化框架之间的关系，提高持久化框架的相对独立性。

阅读材料：《精通Struts：基于MVC的Java Web设计与开发》

                                       2005年05月12日 1:20 AM

Web.xml文件对于配置任何Java Web应用都是必须的.当配置Struts应用时,还应该在web.xml文件中配置和Struts相关的配置选项.一下讲述配置Struts应用的必要步骤.

1·配置Struts的ActionServlet

第一步用<servlet>元素来声明ActionServlet。

在<servlet>的子元素中，经常用到的有：

   ·<servlet-name>元素用来定义Servlet的名称。

   ·<servlet-class>元素用来置顶Servlet的完整类名。

   ·<init-param>元素用于配置Servlet初始化参数。

第二步为配置<servlet-mapping>元素，用来指定ActionServlet可以处理哪些URL。

有子元素<servlet-name>和<url-pattern>，注意，这里的<servlet-name>必须和<servlet>元素中的<servlet-name>匹配。

**提示**

  不管应用中包含多少子应用，都只需要配置一个ActionServlet。有些开发者希望设置多个ActionServlet类来处理应用中不同的功能，其实这是不必要的，因为Serlvet本身支持多线程。而且，目前的Struts框架只允许在应用中配置一个ActionSerlvet。

2·配置欢迎文件清单

<welcome-file-list>元素中可以包含多个<welcome-file>子元素，当Web容器调用Web应用的欢迎文件时，首先寻找第一个<welcome-file>指定的文件。如果这个文件存在，将把这一个文件返回给客户；如果这个文件不存在，Web容器将依次寻找下一个欢迎文件，直到找到为止；如果都不存在，服务器将向客户返回“HTTP 404 Not Found”的出错信息。

3·配置错误处理

<error-page>

  <error-code></error-code>

  <location></location>

</error-page>

如果在web.xml文件中做了以上配置，当Web容器捕获到错误时（如：HTTP 404、HTTP 500），将根据错误代码减缩<error-page>的子元素<error-code>，如果有匹配项就返回<location>子元素指定的文件。

  也可以为Web容器捕获的Java异常配置<error-page>元素，这是需要设置<exception-type>子元素，它用于指定Java异常类。Web容器可能捕获如下异常：

  ·RuntimeException或Error。

  ·ServletException或它的子类。

  ·IOException或它的子类。

这里的配置信息如下：

<error-page>

  <exception-type></exception-type>

  <location></location>

</error-page>

4·配置Struts标签库

<taglib>元素有两个子元素：<taglib-uri>和<taglib-location>。<taglib-uri>元素指定标签库的相对或者绝对URI地址，Web应用将根据这一URI来访问标签库；<taglib-location>元素指定标签库描述文件在文件资源系统中的物理位置。

如果Web应用中没有使用Struts标签库，就没有必要在web.xml文件中配置它。此外，也可以按以上方式在web.xml文件中配置用户自定义的客户化标签库。

                                           2005年04月08日 6:18 PM