ServletJSP深入详解基于Tomcat的Web开发 第三章全格式已整理.docx
《ServletJSP深入详解基于Tomcat的Web开发 第三章全格式已整理.docx》由会员分享，可在线阅读，更多相关《ServletJSP深入详解基于Tomcat的Web开发 第三章全格式已整理.docx（20页珍藏版）》请在冰豆网上搜索。
ServletJSP深入详解基于Tomcat的Web开发第三章全格式已整理
Servlet/JSP深入详解：
基于Tomcat的Web开发--第三章
本章要点
—掌握配置任意目录下的Web应用程序
—掌握以WAR文件的形式发布Web应用程序
—掌握与Servlet配置相关的元素的使用
Web应用程序的开发分为设计开发与配置部署两个阶段。
通过部署，实现了组件与组件之间的松耦合，降低了Web应用程序的维护难度。
本章主要介绍以下几个主题：
—如何配置任意目录下的Web应用程序
—如何以WAR文件的形式发布Web应用程序
—与Servlet配置相关的元素的使用
3.1 配置任意目录下的Web应用程序
一个Web容器可以运行多个Web应用程序，每个Web应用程序都有一个唯一的上下文根，上下文根如何部署是和具体的Web容器相关的。
对于Tomcat来说，%CATALINA_HOME%\webapps目录下的每一个子目录都是一个独立的Web应用程序，这个子目录的名字就是这个Web应用程序的上下文根。
例如，第2章的Web应用程序位于%CATALINA_HOME%\webapps\ch02目录，上下文根就是ch02。
在部署和访问Web应用程序时，通过上下文路径（contextpath）来区分不同的Web应用程序。
上下文路径以斜杠（/）开头，但结束没有斜杠（/）。
在默认上下文中，这个路径将是空字符串""。
例如：
/ch02是第2章的Web应用程序的上下文路径，凡是发往/ch02路径的请求，都会交由这个路径下的Web应用程序的资源来进行响应。
在第2章中，我们将开发的Web应用程序放在了%CATALINA_HOME%\webapps目录下，当Tomcat启动时，会自动加载webapps目录下的Web应用程序，所以在这个目录下的Web应用程序不需要进行其他的配置就可以直接访问了。
但是，我们在开发的时候，经常会建立自己的开发目录，在开发阶段完成后，才进入正式的产品部署阶段。
如果每当我们完成一个功能，需要测试运行的时候，都要将文件复制到webapps目录下对应的Web应用程序目录中，那未免太烦琐了。
我们知道，在Web服务器中可以配置虚拟目录，而虚拟目录所对应的真实目录可以在任何路径下。
同样地，在Tomcat中，也有类似的配置，这主要是在XML配置文件中通过元素的设置来完成的。
一个元素就表示一个Web应用程序，运行在特定的虚拟主机中。
元素的常用属性如表3-1所示。
表3-1 元素的常用属性
属 性
描 述
className
指定实现了org.apache.catalina.Context接口的类名。
如果没有指定类名，将使用标准的实现。
标准的实现类是org.apache.catalina.core.StandardContext
cookies
指示是否将Cookie应用于Session，默认值是true
crossContext
如果设置为true，在应用程序内部调用ServletContext.getContext（）将成功返回运行在同一个虚拟主机中的其他Web应用程序的请求调度器。
在注重安全的环境中，将该属性设为false，那么getContext（）将总是返回null。
默认值是false
docBase
指定Web应用程序的文档基目录或者WAR文件的路径名。
可以指定目录的或WAR文件的绝对路径名，也可以指定相对于Host元素的appBase目录的路径名。
该属性是必需的
path
指定Web应用程序的上下文路径。
在一个特定的虚拟主机中，所有的上下文路径都必须是唯一的。
如果指定一个上下文路径为空字符串（""），则定义了这个虚拟主机的默认Web应用程序，负责处理所有的没有分配给其他Web应用程序的请求
reloadable
如果设置为ture，Tomcat服务器在运行时，会监视WEB-INF/classes和WEB-INF/lib目录下类的改变，如果发现有类被更新，Tomcat服务器将自动重新加载该Web应用程序。
这个特性在应用程序的开发阶段非常有用，但是它需要额外的运行时开销，所以在产品发布时不建议使用。
该属性的默认值是false
unpackWAR
如果为true，Tomcat在运行Web应用程序前将展开所有压缩的Web应用程序。
默认值是true
元素是元素的子元素，可以在%CATALINA_HOME%\conf\server.xml文件中设置Context元素。
例如，针对第2章的Web应用程序，可以做如下配置：
unpackWARs="true"autoDeploy="true"
xmlValidation="false"xmlNamespaceAware="false">
…
在元素中使用的属性的含义在表3-1中已经列出了，这里就不再讲述了。
在Tomcat中，我们还可以把元素放在下列位置的文件中。
①%CATALINA_HOME%\conf\context.xml文件，在这个文件中设置的信息将被所有的Web应用程序所加载。
②%CATALINA_HOME%\conf\[enginename]\[hostname]\context.xml.default文件，[enginename]表示的是在server.xml文件中设置的元素的name属性的值，[hostname]表示的是在server.xml文件中设置的元素的name属性的值，关于servet.xml文件的详细信息，可以参看附录C。
在笔者的机器上，%CATALINA_HOME%\conf\server.xml文件中元素的name属性的值是Catalina，元素的name属性的值是localhost，你可以在%CATALINA_HOME%\conf目录下依次创建Catalina\localhost目录，然后在localhost目录下新建context.xml.default文件，在这个文件中设置的信息将被属于该虚拟主机的所有Web应用程序所加载。
③可以为一个Web应用程序建立%CATALINA_HOME%\conf\[enginename]\[hostname]\xxx.xml文件，在这个XML文件中，元素的docBase属性通常是Web应用程序目录的绝对路径名，或者是Web应用程序归档文件的绝对路径名。
④在Web应用程序的目录结构中增加META-INF\context.xml文件。
包含META-INF子目录的Web应用程序的目录层次结构如图3-1所示。
在%CATALINA_HOME%\webapps目录下的Web应用程序，如果没有在任何文件中设置元素，那么Tomcat将为这个Web应用程序自动生成元素。
自动生成的元素的上下文路径将以斜杠（/）开始，后面紧跟Web应用程序所在目录的名字，如果目录的名字是ROOT，那么上下文路径将是一个空字符串（""）。
所以在%CATALINA_HOME%\webapps目录下的Web应用程序可以不经配置而直接使用。
在%CATALINA_HOME%\webapps目录下有一个ROOT目录，Tomcat为ROOT目录生成的元素的上下文路径是空字符串（""），而我们知道，如果一个Web应用程序的上下文路径是空字符串（""），则这个Web应用程序将作为虚拟主机的默认Web应用程序，负责处理所有的没有分配给其他Web应用程序的请求，这也就是为什么我们访问http:
//localhost:
8080/时，访问的是%CATALINA_HOME%\webapps\ROOT目录下的资源。
如果我们想将开发的目录直接配置成Web应用程序运行的目录，而不是将这个目录复制到%CATALINA_HOME%\webapps目录下，可以在两处地方进行配置。
例如，在笔者的机器上，本章的例子程序所在目录是F:
\JSPLesson\ch03，为了可以直接在这个目录下运行Web应用程序，我们编辑%CATALINA_HOME%\conf\server.xml文件，设置元素，如例3-1所示。
例3-1 在server.xml中设置元素
unpackWARs="true"autoDeploy="true"
xmlValidation="false"xmlNamespaceAware="false">
…
使用docBase属性指定Web应用程序的真实路径。
将属性reloadable设置为true，Tomcat在运行时会自动监测Servlet类的改动，如果发现有类被更新，Tomcat服务器将自动重新加载该Web应用程序。
这样，在开发时，我们就不需要频繁重启Tomcat了。
读者可以将ch03目录按照Web应用程序的目录层次结构建好，然后编写一个简单的输出“HelloWorld”的Servlet进行测试，步骤和第2章的实例程序的编写步骤是一样的。
此外，我们还可以在%CATALINA_HOME%\conf目录下依次创建Catalina\localhost目录，然后在localhost目录下为ch03这个Web应用程序建立ch03.xml文件，编辑这个文件，输入如例3-2所示的内容。
例3-2 ch03.xml
读者可以用自己编写的Servlet类进行测试，在测试之前，要先把server.xml文件中设置的元素删除或注释起来。
从Tomcat5开始，不建议直接在server.xml文件中配置元素，因为server.xml文件作为Tomcat的主要配置文件，一旦Tomcat启动后，将不会再读取这个文件，因此你无法在Tomcat服务器启动时发布Web应用程序。
如果在其他地方配置元素，那么在Tomcat运行时，也可以发布Web应用程序。
从Tomcat5.5开始，在%CATALINA_HOME%\conf\[enginename]\[hostname]\目录下创建XML配置文件来配置Web应用程序，Tomcat将以XML文件的文件名将作为Web应用程序的上下文路径，而不管你在元素的path属性中指定的上下文路径是什么。
例如，文件名是ch03.xml，元素的path属性设置为/hello，那么执行http:
//localhost:
8080/hello/helloworld将提示HTTP404错误，如果执行http:
//localhost:
8080/ch03/helloworld将显示正确的输出信息。
而Tomcat5.5之前的版本则是以元素的path属性的值作为上下文的路径。
由于Tomcat5.5之后的版本是以XML配置文件的文件名作为Web应用程序的上下文路径的，因此在配置元素时，可以不使用path属性。
%CATALINA_HOME%\conf\web.xml为运行在同一个Tomcat实例中的所有Web应用程序定义了默认值。
当Tomcat加载一个Web应用程序的时候，首先读取这个文件，然后再读取Web应用程序目录下的WEB-INF/web.xml文件。
3.2 WAR文件
如果一个Web应用程序的目录和文件非常多，那么将这个Web应用程序部署到另一台机器上，就不是很方便了，我们可以将Web应用程序打包成Web归档（WAR）文件，这个过程和把Java类文件打包成JAR文件的过程类似。
利用WAR文件，可以把Servlet类文件和相关的资源集中在一起进行发布。
在这个过程中，Web应用程序就不是按照目录层次结构来进行部署了，而是把WAR文件作为部署单元来使用。
一个WAR文件就是一个Web应用程序，建立WAR文件，就是把整个Web应用程序（不包括Web应用程序层次结构的根目录）压缩起来，指定一个.war扩展名。
下面我们将第2章的Web应用程序打包成WAR文件，然后发布。
WAR文件的创建与JAR文件的创建使用相同的命令。
打开命令提示符，进入%CATALINA_HOME%\webapps\ch02\目录，执行下面的命令：
jar-cvfch02.war*
这个命令将ch02目录下所有的子目录和文件都打包成一个名为ch02.war的归档文件。
如果不想包含src目录及其下的Java源文件（在发布时不应该把Java源文件包含到WAR文件中），可以执行下面的命令：
jar-cvfch02.war*.htmlWEB-INF/
要查看WAR文件的内容，可以执行下面的命令：
jar-tfch02.war
这个命令将列出WAR文件的内容，或者用WinRAR工具软件查看ch02.war文件的内容，如图3-2所示。
图3-2 使用WinRAR查看ch02.war文件
如果修改了某个Servlet类文件，需要替换WAR文件中的旧文件，可以执行下面的命令：
jar-ufch02.warWEB-INF/classes/org/sunxin/ch02/servlet/LoginServlet.class
当然你也可以利用WinRAR软件来更新压缩包中的文件。
如果我们将ch02.war文件放到%CATALINA_HOME%\webapps目录下，在Tomcat启动时，会自动解压这个WAR文件，按照打包前的目录层次结构生成与WAR文件的文件名同名的目录ch02及下面的子目录和文件。
读者可以自己动手做一下实验，先删除在%CATALINA_HOME%\webapps目录下的ch02目录，然后将ch02.war文件复制到%CATALINA_HOME%\webapps目录下，启动Tomcat，你会看到在webapps目录下新产生了一个ch02目录。
当然，我们也可以直接从WAR文件运行Web应用程序，打开%CATALINA_HOME%\conf\server.xml文件，找到元素的配置处，如下所示：
unpackWARs="true"autoDeploy="true"
xmlValidation="false"xmlNamespaceAware="false">
…
将unpackWARs属性的值设置为false，这样，Tomcat将直接运行WAR文件。
关于元素各属性的含义，请参看附录C或Tomcat的文档。
删除Tomcat产生的目录ch02，重新启动Tomcat，查看%CATALINA_HOME%\webapps目录，可以看到这次没有产生ch02目录，打开浏览器，输入以前访问过的URL进行测试。
在建立WAR文件之前，需要建立正确的Web应用程序的目录层次结构。
—建立WEB-INF子目录，并在该目录下建立classes与lib两个子目录。
—将Servlet类文件放到WEB-INF\classes目录下，将Web应用程序所使用Java类库文件（即JAR文件）放到WEB-INF\lib目录下。
—建立web.xml文件，放到WEB-INF目录下。
—根据Web应用程序的需求，将JSP页面或静态HTML页面放到上下文根路径下或其子目录下。
—如果有需要，建立META-INF目录，并在该目录下建立context.xml文件。
只有在确保这些工作后都完成后，才开始建立WAR文件。
要注意的是，虽然WAR文件和JAR文件的文件格式是一样的，并且都是使用jar命令来创建，但就其应用来说，WAR文件和JAR文件是有根本区别的。
JAR文件的目的是把类和相关的资源封装到压缩的归档文件中，而对于WAR文件来说，一个WAR文件代表了一个Web应用程序，它可以包含Servlet、HTML页面、Java类、图像文件，以及组成Web应用程序的其他资源，而不仅仅是类的归档文件。
我们什么时候应该使用WAR文件呢？
在开发阶段不适合使用WAR文件，因为在开发阶段，经常需要添加或删除Web应用程序的内容，更新Servlet类文件，而每一次改动后，重新建立WAR文件将是一件浪费时间的事情。
在产品发布阶段，使用WAR文件是比较合适的，因为在这个时候，几乎不需要再做什么改动了。
在开发阶段，我们通常将Servlet源文件放到Web应用程序目录的src子目录下，以便和Web资源文件区分。
在建立WAR文件时，只需要将src目录从Web应用程序目录中移走，就可以打包了。
3.3 与Servlet配置相关的元素
3.3.1 元素及其子元素
在web.xml文件中，元素及其可以包含的子元素如图3-3所示。
图3-3 元素及其子元素
图3-3中的*表示可以有零个或多个子元素，?
表示可以有零个或一个子元素，除此之外的元素为必备的元素。
下面我们对元素的各个子元素的含义做一个说明。
Ø
为Servlet指定一个文本描述。
Ø
为Servlet指定一个简短的名字，这个名字可以被某些工具所显示。
Ø
为Servlet指定一个图标。
这个图标可以在一些图形界面工具中用于表示该Servlet。
Ø
指定Servlet的名字，这个名字在同一个Web应用程序中必须是唯一的。
这个元素在第2章的例子中已经使用过。
Ø
指定Servlet类的完整限定名。
这个元素在第2章的例子中也已经使用过。
Ø
指定在Web应用程序中的JSP文件的完整路径，该路径以斜杠（/）开始。
如果要对一个JSP文件做URL映射，就会用到这个元素。
Ø
定义Servlet的初始化参数。
如果使用了元素，则必须包含和元素，可以包含零个或多个元素。
—
为初始化参数提供一个文本描述。
—
定义初始化参数的名字。
—
定义初始化参数的值。
Ø
指定当Web应用程序启动时，Servlet被加载的次序。
元素的内容必须是一个整数，如果这个值是一个负数，或者没有设定这个元素，Servlet容器将在客户端首次请求这个Servlet时加载它；如果这个值是正数或0，容器将在Web应用程序部署时加载和初始化这个Servlet，并且先加载数值小的Servlet，后加载数值大的Servlet。
如果某个Servlet需要在其他Servlet被加载之前加载，可以在部署描述符中使用这个元素。
如果元素包含了元素和元素，则JSP文件将被预编译并加载。
Ø
指定用于执行组件的角色。
如果使用了元素，可以包含零个或多个元素，必须包含元素。
—
指定一个文本描述。
—
指定用于执行组件的角色名。
Ø
声明在组件或部署的组件的代码中的安全角色引用。
如果使用了元素，则必须包含元素，可以包含零个或多个元素，零个或一个元素。
—
为安全角色引用提供一个文本描述。
—
指定在代码中使用的安全角色的名字。
—
指定到一个安全角色的引用。
3.3.2 元素及其子元素
元素在Servlet和URL样式之间定义一个映射。
它包含了两个子元素和，元素给出的Servlet名字必须是在元素中声明过的Servlet的名字。
元素指定对应于Servlet的URL路径，该路径是相对于Web应用程序上下文根的路径。
例如：
helloworld
/hello
Servlet2.5规范允许的子元素出现多次，之前的规范只允许一个元素包含一个子元素。
我们看下面的例子：
welcome
/en/welcome
/zh/welcome
在配置了Servlet与URL样式之间的映射后，当Servlet容器接收到一个请求，它首先确定该请求应该由哪一个Web应用程序来响应。
这是通过比较请求URI的开始部分与Web应用程序的上下文路径来确定的。
映射到Servlet的路径是请求URI减去上下文的路径，Web应用程序的Context对象在去掉请求URI的上下文路径后，将按照下面的路径映射规则的顺序对剩余部分的路径进行处理，并且在找到第一个成功的匹配后，不再进行下一个匹配。
—容器试着对请求的路径和Servlet映射的路径进行精确匹配，如果匹配成功，则调用这个Servlet来处理请求。
—容器试着匹配最长的路径前缀，以斜杠（/）为路径分隔符，按照路径树逐级递减匹配，选择最长匹配的Servlet来处理请求。
—如果请求的URL路径最后有扩展名，如.jsp，Servlet容器会试着匹配处理这个扩展名的Servlet。
—如果按照前面3条规则没有找到匹配的Servlet，容器会调用Web应用程序默认
升级会员 