Tomcat是Java开发者使用得较多的一个Web服务器，因为它占用资源小，运行速度快等特点，深受Java Web程序员的喜爱。不过，在使用中，由于Java中的中文问题的存在，如果不经过配置，在WEB程序中，不能直接支持具有中文文件名的文件的下载，这为Java Web程序的开发带来一定的不便。本文拟介绍一种手段，解决这个问题。

   解决问题的核心在于修改Tomcat的配置，在Server.xml文件中添加一个名为URIEncoding的属性，它用于对HTTP请求中的get方法传过来的URL进行编码。如果直接从Apache站点中下载Tomcat，无论是安装版的exe文件，还是解压缩的ZIP文件，内置的对于get协议中的URL编码都是ISO-8859-1,这个字符集不能直接支持中文等双字节的信息，而中文文件的下载链接恰恰是通过get协议进行的。以下说明修改Tomcat安装目录中的config文件夹中的server.xml文件的方法。

   打开config/server.xml文件，如果没有修改过这个文件，应该可以在其中找到如下代码：
  
   <Connector port="8080"  protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
  
   这段代码规定了Tomcat监听HTTP请求的端口号等信息，可以在这里添加一个属性：URIEncoding，将该属性值设置为UTF-8，即可让Tomcat不再以ISO-8859-1的编码处理get请求。更改后的代码如下所示（红色部分为新添加的代码）：
 
  <Connector port="8080"
             URIEncoding="utf-8"
             protocol="HTTP/1.1"
             connectionTimeout="20000"
             redirectPort="8443" />
 
  下面，我们准备测试一下更改后的效果。

   最为简单的测试方法就是让Tomcat自己列出WEB程序中的目录和文件，默认情况下，Tomcat不会直接列出WEB程序目录中的文件和文件夹，但是，我们可以修改位于安装目录中的config文件夹中的web.xml，使其能够支持自动列出WEB程序中的目录和文件。
   在config/web.xml文件中找到如下代码：
  
    <servlet>
    <servlet-name>default</servlet-name>
    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
    <init-param>
      <param-name>debug</param-name>
      <param-value>0</param-value>
    </init-param>
    <init-param>
      <param-name>listings</param-name>
      <param-value>false</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
  
   将上面的代码中标为红色的部分改为如下内容：
 
   <init-param>
      <param-name>listings</param-name>
      <param-value>true</param-value>
   </init-param>
  

   即将参数listings的属性改为true，就可让Tomcat自动列出某个WEB程序目录中的文件和文件夹。

   现在，我们的设置已经完成，将修改的文件保存后，就可以启动Tomcat进行测验了，当然，如果Tomcat正在运行，则需要重新启动，以便配置生效。

   现在，可以在Tomcat安装目录中的webapps目录中建立一个名为cntest的文件夹，作为测试的web程序的上下文路径（注意：对于WEB程序的上下文路径，请不要使用中文）。请在cntest中添加一些中文目录和文件，然后在浏览器中打开该WEB程序，如，http://localhost:8080/cntest，测验一下效果吧。当然，也可以在JSP或HTML文件中使用那些包含中文的文件夹或文件名的超级链接。

   说明：以上修改均使用Tomcat5.5做的测试，在5.5以上都应该可以，至于5.0和4.x，我没有实验过，不过对于5.0应该也是可以的，但4.x不能保证（4.x在处理HTTP的get和post方法和5.x不大一样）。

出现了这样的错误提示： weblogic.management.DeploymentException: [HTTP Session:100039]Replicated HTTP sessions specified for webapp: /admin, but clustering not enabled    

 

后面终于发现了错误的原因， 这个错误的原因在于weblogic.xml身上，
weblogic.xm里面的
<session-descrīptor>
<session-param>
<param-name>PersistentStoreType</param-name>
<param-value>replicated</param-value>
</session-param>
</session-descrīptor>

把 replicated 改为 memory 就解决了。或者把这个字段去掉

Tomcat服务器是一个免费的开放源代码的Web应用服务器。因为Tomcat技术先进、性能稳定且免费，所以深受Java爱好者的喜爱并得到了部分软件开发商的认可，成为目前比较流行的Web应用服务器。

一、Tomcat与应用服务器

到目前为止，Tomcat一直被认为是Servlet/JSP API的执行器，也就所谓的Servlet容器。然而，Tomcat并不仅仅如此，它还提供了JNDI和JMX API的实现机制。尽管如此，Tomcat仍然还不能算是应用服务器，因为它不提供大多数J2EE API的支持。

很有意思的是，目前许多的应用服务器通常把Tomcat作为它们Servlet和JSP API的容器。由于Tomcat允许开发者只需通过加入一行致谢，就可以把Tomcat嵌入到它们的应用中。遗憾的是，许多商业应用服务器并没有遵守此规则。

对于开发者来说，如果是为了寻找利用Servlet、JSP、JNDI和JMX技术来生成 Java Web应用的话，选择Tomcat是一个优秀的解决方案；但是为了寻找支持其他的J2EE API，那么寻找一个应用服务器或者把Tomcat作为应用服务器的辅助，将是一个不错的解决方案；第三种方式是找到独立的J2EE API实现，然后把它们跟Tomcat结合起来使用。虽然整合会带来相关的问题，但是这种方式是最为有效的。。

二、Tomcat与Web服务器

Tomcat是提供一个支持Servlet和JSP运行的容器。Servlet和JSP能根 据实时需要，产生动态网页内容。而对于Web服务器来说， Apache仅仅支持静态网页，对于支持动态网页就会显得无能为力；Tomcat则既能为动态网页服务，同时也能为静态网页提供支持。尽管它没有通常的 Web服务器快、功能也不如Web服务器丰富，但是Tomcat逐渐为支持静态内容不断扩充。大多数的Web服务器都是用底层语言编写如C，利用了相应平 台的特征，因此用纯Java编写的Tomcat执行速度不可能与它们相提并论。

一般来说，大的站点都是将Tomcat与Apache的结合，Apache负责接受所有来自客户端的HTTP请求，然后将Servlets和JSP的请求转发给Tomcat来处理。Tomcat完成处理后，将响应传回给Apache，最后Apache将响应返回给客户端。

通俗的讲，Web服务器传送(serves)页面使浏览器可以浏览，然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法 (methods)。确切一点，你可以说：Web服务器专门处理HTTP请求(request)，但是应用程序服务器是通过很多协议来为应用程序提供 (serves)商业逻辑(business logic)。

下面让我们来细细道来：

Web服务器(Web Server)
Web 服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request)，会返回一个HTTP响应 (response)，例如送回一个HTML页面。为了处理一个请求(request)，Web服务器可以响应(response)一个静态页面或图片， 进行页面跳转(redirect)，或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本，JSP(JavaServer Pages)脚本，servlets，ASP(Active Server Pages)脚本，服务器端(server-side)Javascrīpt，或者一些其它的服务器端(server-side)技术。无论它们(译者 注：脚本)的目的如何，这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。

要 知道，Web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到Web服务器里来时，它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注：服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响 应(response)的环境，而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing)，数据库连接(database connectivity)和消息(messaging)等功能。

虽然Web服 务器不支持事务处理或数据库连接池，但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability)，例如负载平衡(load balancing)，缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。

应用程序服务器(The Application Server)
根 据我们的定义，作为应用程序服务器，它通过各种协议，可以包括HTTP，把商业逻辑暴露给(expose)客户端应用程序。Web服务器主要是处理向浏览 器发送HTML以供浏览，而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法(或过程语言 中的一个函数)一样。

应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至是其它 的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反，这种信息就是程序逻辑 (program logic)。正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML，所以客户端才可以随心所欲的使用这种被暴露 的商业逻辑。

在大多数情形下，应用程序服务器是通过组件(component)的应用程序接口(API)把商业逻辑暴露(expose) (给客户端应用程序)的，例如基于J2EE(Java 2 Platform, Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外，应用程序服务器可以管理自己的资源，例如看大门的工作(gate-keeping duties)包括安全(security)，事务处理(transaction processing)，资源池(resource pooling)，和消息(messaging)。就象Web服务器一样，应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。

一个例子
例如，设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询 (query)后，网站会进行查找(lookup)并把结果内嵌在HTML页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序 服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。

情景1：不带应用程序服务器的Web服务器

在 此种情景下，一个Web服务器独立提供在线商店的功能。Web服务器获得你的请求(request)，然后发送给服务器端(server-side)可以 处理请求(request)的程序。此程序从数据库或文本文件(flat file，译者注：flat file是指没有特殊格式的非二进制的文件，如properties和XML文件等)中查找定价信息。一旦找到，服务器端(server-side)程序 把结果信息表示成(formulate)HTML形式，最后Web服务器把会它发送到你的Web浏览器。

简而言之，Web服务器只是简单的通过响应(response)HTML页面来处理HTTP请求(request)。

情景2：带应用程序服务器的Web服务器

情 景2和情景1相同的是Web服务器还是把响应(response)的产生委托(delegates)给脚本(译者注：服务器端(server- side)程序)。然而，你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化，此脚本只是简单的调用应用程序服务器的查找服务(lookup service)，而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。这时当该脚本程序产生HTML响应 (response)时就可以使用该服务的返回结果了。

在此情景中，应用程序服务器提供(serves)了用于查询产品的定价信息的商业 逻辑。(服务器的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细节，相反客户端和应用程序服务器只是来回传送数 据。当有客户端调用应用程序服务器的查找服务(lookup service)时，此服务只是简单的查找并返回结果给客户端。

通过从响应 产生(response-generating)HTML的代码中分离出来，在应用程序之中该定价(查找)逻辑的可重用性更强了。其他的客户端，例如收款 机，也可以调用同样的服务(service)来作为一个店员给客户结帐。相反，在情景1中的定价查找服务是不可重用的因为信息内嵌在HTML 页中了。

总而言之，在情景2的模型中，在Web服务器通过回应HTML页面来处理HTTP请求(request)，而应用程序服务器则是通过处理定价和有效性(availability)请求(request)来提供应用程序逻辑的。

警告(Caveats)
现在，XML Web Services已经使应用程序服务器和Web服务器的界线混淆了。通过传送一个XML有效载荷(payload)给服务器，Web服务器现在可以处理数据和响应(response)的能力与以前的应用程序服务器同样多了。

另 外，现在大多数应用程序服务器也包含了Web服务器，这就意味着可以把Web服务器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器 包含了Web服务器的功能，但是开发者很少把应用程序服务器部署(deploy)成这种功能(capacity)(译者注：这种功能是指既有应用程序服务 器的功能又有Web服务器的功能)。相反，如果需要，他们通常会把Web服务器独立配置，和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单 的Web请求(request)就不会影响应用程序服务器了)，分开配置(专门的Web服务器，集群(clustering)等等)，而且给最佳产品的选 取留有余地。

CLUSTER概要
一、 Cluster的概念及优势

Weblogic支持集群技术，即让一组Server指向同一域名一起工作从而提供一个更强大、更可靠的应用平台。对于客户端而言，无论Cluster中有几个Server在工作，看上去都是一个。集群技术有两个最明显的特色：
(1)可伸缩性：Cluster对加入其中的Server在性能上没有限制，为了提高性能，当客户端的请求大幅增加时，可以动态地向Cluster中添加Server。并且，配置Cluster当一台机器的资源没有被完全利用时，可以在同一机器上启动多个Server，但要求每一个Server使用不同的IP，而不能用同一IP的不同端口。
(2)高可用性：由于在Cluster中同一service在多个Server上同时存放或放在一个共享文件系统中，因此相同的请求可以有多个Server提供，并且Server间还可以复制状态信息。这样，当其中某一Server宕机或无法响应请求时，其它的Server会立即接管它的任务，从而把应用和客户端完全隔离开来。

二、Cluster的工作机制
每一个Clustered service,在每一个server上都会有一个instance，即一个replica，这些replicas集合在一起形成一个replica-aware stub。这些stubs负责客户端与相关的服务器段对象的通信，当客户端请求该service时，实际上是向stub发出请求，stub根据不同的算法调用集合中某一replica，如果调用失败，stub会检测到错误并重新调用其它的replica。Cluster支持多种算法：随机、轮循、基于性能的负载均衡的轮循(Weight-based round-robin)、根据参数值调用(Parameter-based routing)。
Weblogic Cluster通过负载均衡和容错最大程度的实现了它的可伸缩性和可用性。
为了提高Cluster的可伸缩性，必须保证充分利用每一个Server。Weblogic可以在不同平台、不同性能的机器上安装Server并进行Cluster,然后采用Weight-based round-robin算法达到负载均衡，从而使每一个Server都得到充分的利用。
为了使Cluster具有高可用性，必须具备故障恢复的能力，这一点可以通过replica-aware stub的容错功能来实现。Stub 主要是通过在检测到错误信息时重新进行调用的方式实现容错。当重新调用不会导致错误的结果时(如stub确认failed server不能接收到请求)，容错功能自动实现。而有些情况下，重新调用可能会导致某一service被请求了多次的错误结果。例如：客户端C请求Clustered购物车服务中的additem()方法，replica-aware stub接收到请求，根据算法调用Server1上的service,Server1响应请求并返回结果，但在结果成功到达客户端之前，Server1出现错误。此时stub接收到错误信息，因此重新调用Server2上的这一方法，但实际上Server1已经将item加入购物车，这样就造成重复。为了解决这种问题，可以为服务添加一个唯一标识，如上述的additem()方法中可添加一个参数——序列号。每一个item有一个唯一的sequence,相同sequence的item不能被重复添加。

三、 Cluster的命名服务

在Weblogic Server中使用命名服务时，客户端通过JNDI存取service，JNDI tree上绑定了Server提供的所有的公共服务。Server提供一个新的service时，是将service以某一名称绑定到JNDI tree上，客户端和Server建立连接并按照名称获取相应的stub。
Custer扩展了Server的这种命名服务机制，它不仅包含了每一个Server上的非Clustered的stub,而且包含了多个Server间的Clustered 的replica-aware stub。

四、 Cluster的服务类型

在Weblogic中，有多种服务可以进行cluster，如：RMI对象、EJB、Servlets、Jsp、Web Application。

（1）RMI和EJB Clustering
RMI和EJB对象在Cluster过程中使用JNDI命名服务机制。RMI和EJB对象发送remote stubs到客户端，客户端获取的这些stubs可以是已经clustered的，也可以是没有clustered的。对于Clustered的服务，Stubs根据负载均衡和容错的不同需求调用Cluster中合适的Server；而对没有Clustered的服务，所有对此stub的调用只能由提供此服务的Server来处理。
有些有状态的RMI和EJB对象是不可以进行clustered的，因为客户端必须总是和同一个Server上的对象实例相联系。所有的EJB都是clusterable，虽然EJB也有有状态的，但是EJB home interface 都是无状态的，可以进行clustered，这样就可以从JNDI tree上获取 Clusterable EJB 的home stub 对象。然后通过home stub的方法创建或检索相应的EJB bean,若为stateful session bean 或entity bean，那么此时得到的stub就是不可clusterable。为了使有状态的对象可以更好的cluster，可以将一些操作作为一个事务来执行，如果工作中的Server出现意外，可以重新获取此对象并进行事务操作。
RMI和EJB不同，RMI没有定义有状态和无状态分类，因此必须特意绑定一个有状态的RMI对象到Server上。可以仿效EJB home interface的方式即客户端从JNDI tree上获取一个clusterable factory method,然后factory method 可以调用集群中的任意一台Server,但是被调用的Server上必须有由此factory调用的对象。

（2）Clustered Servlets
Servlets也是可以进行Cluster的。对于Servlets，它用replica-aware proxy替代了replica-aware。这个proxy接受web server上所有请求，并转给集群中的某一Server。Proxy对cluster的所有请求进行负载均衡，并且当请求失败时会进行恢复处理。Proxy还可以在cluster中特别是Server没有正常完成请求响应时保持session状态。当session初始化时，proxy按照负载均衡算法选择一台Server保存session，此后，所有与此session相关的请求都由这同一台Server处理。为了避免当此Server出错时，无法保存客户端状态信息，所以session会被复制下来，并且session的所有变化都会在备份中进行及时更新，这样，当原有Server在响应请求过程中失败时，proxy会立即获取session的备份，并由此继续响应客户端请求，同时做新的复制。

(3)JDBC clustering
为了利用Weblogic Server cluster的负载均衡和容错的性能，Weblogic JDBC连接池也可以在replicated naming tree上注册。通常情况下，cluster中的每一个Server都进行连接池属性配置来访问同一个后端的DBMS实例，即对相同数据库的访问，每一个Server都有一个连接池。然后通过在配置文件中定义一个DataSource属性来在naming tree 上注册连接池。客户端使用Weblogic JDBC/RMI JDBC 驱动程序从cluster中获取数据库连接，即客户端按照DataSource name获取连接池，然后按照负载均衡的算法选择相应的Weblogic Server来响应请求。

JAR文件简介

JAR文件以流行的二进制ZIP文件格式为基础，用以把许多文件合并成一个文件。它还包含一个名为META-INF的可选目录，这个目录位于文件根目录下。

有两种方法可以建立JAR文件：应用命令行工具jar，或使用Java中的java.util.jar API编程。如果JAR文件包含在Java类路径中，使JVM可看到它，则JAR文件包含Java类和/或可由类加载器运行、使用及加载的资源。

在许多情况下，JAR文件不仅仅是简单的Java类档案文件和/或资源；它们还可用来为应用程序和扩展建立语句块。META-INF目录（如存在）用于存储数据包和扩展配置数据，包括安全、版本、扩展和服务。

META-INF目录的作用

META-INF目录中的下列文件和目录获得Java 2平台的认可与解释，用来配置应用程序、扩展程序、类加载器和服务：

MANIFEST.MF：清单文件，用来定义与扩展和数据包相关的数据。

INDEX.LIST：这个文件由JAR工具的新“-i”选项生成，其中包含在一个应用程序或扩展中定义的数据包的地址信息。它是JarIndex的一部分，被类加载器用来加速类加载过程。

x.SF：JAR文件的签名文件。x代表基础文件名。

x.DSA：这个签名块文件与同名基础签名文件有关。此文件存储对应签名文件的数字签名。

services/：这个目录存储所有服务提供程序配置文件。

下面我们来了解一下每种组合。

清单文件

清单文件由“AttributeName: Value”对构成，一个换行符将其划分成两个部分：主要部分和单独部分，这两个被另外一个换行符分开。

主要部分：这个部分包含JAR文件本身的安全和配置信息，以及此JAR文件构成的应用程序或扩展。它还定义适用于每个单独清单项的主要属性。这个部分没有名为“Name”的属性。本部分以一个空行结束。

单独部分：这个部分为此JAR文件中包含的数据包或文件定义各种属性。并非所有的JAR文件都必须列举在清单文件中，但必须列出所有签名文件。清单文件本身不得列出。每个部分必须以一个名为“Name”的属性开始，它的值必须是一个文件相对路径，或档案文件外的一个绝对URL参考数据。（我将在本文后部分讨论JAR签名。）

下面是清单文件最重要的属性：

Manifest-Version：定义清单文件版本。它的值是一个上面规范描述的合法版本号。

Created-By：详细说明生成这个清单文件的Java程序的版本和生产商。这个属性由JAR工具生成。

Signature-Version：定义JAR文件的签名版本。该值应为一个有效的版本号字符串。

Class-Path：这个属性值指定这个应用程序或扩展需要的扩展或库的相对URL。URL由一个或几个空格分隔。应用程序或扩展类加载器使用这个属性值建立它的内部搜索路径。

Main-Class：这个属性用于单机应用程序。这个属性值定义主要应用程序类的相对路径，发射器在启动时会加载这些类。这个属性值不能在类名称后附加.class扩展名。如果你已经指定这个属性，JAR文件即变成可执行文件，应用程序将通过java –jar x.jar命令自动启动。

Sealed：这个属性定义此JAR文件是否被密封。该值可为真或假，且忽略大小写。当JAR文件被密封时，一个可选的数据包可在某个特殊的版本中执行一贯性。在JAR中密封的数据包规定所有在那个数据包中定义的类必须源自相同的JAR；否则，就会产生一个SecurityException。例如，这段代码：

Name: javax/servlet/internal/

Sealed: true

说明javax.servlet.internal数据包被密封，且这个数据包中的所有类必须从相同的JAR文件加载。要了解可选数据包的详细内容，请查看扩展机制。

JAR签名文件

任何JAR文件都可以通过java.security API，使用命令行jarsigner工具或目录进行签名。通过文件签名，你可以保证没人能够改变一个文件的内容，以及你正在使用一个知名厂商的JAR文件。如果JAR文件用jarsigner工具签名，那么每个文件，包括META-INF目录中的相关非签名文件，都将被签名。下面是与签名有关的文件：

META-INF/MANIFEST.MF

META-INF/*.SF

META-INF/*.DSA

META-INF/*.RSA

META-INF/SIG-*

每个签名器由一个扩展名为.SF的签名文件说明，这个文件的主要内容与清单文件相似。它由一个主要部分构成，其中包含由签名器提供的信息，但并不特别针对某个特定的JAR文件。主要部分的项目x-Digest-Manifest-Main-Attributes（这里的x是一个摘要算法）包含清单主要属性的摘要值。

要使一个文件生效，首先将签名文件的一个摘要值与根据清单文件中对应的项目计算的摘要进行比较；然后，再将清单文件中的一个摘要值与根据“Name：”属性中的实际引用数据计算的摘要比较。“Name：”属性指定一个相对文件路径或RUL。

例如，下面是一个签名JAR的清单文件：

Manifest-Version: 1.0

Created-By: 1.3 (Sun Microsystems, Inc)?br>

Name: common/class1.class

MD5-Digest: (base64 representation of MD5 digest)?br>

Name: common/class2.class

MD5-Digest: (base64 representation of MD5 digest)

SHA-Digest: (base64 representation of SHA digest)

下面是对应的签名：

Signature-Version: 1.0

MD5-Digest-Manifest-Main-Attributes: (base64 representation of MD5 digest)?br>

Name: common/class1.class

MD5-Digest: (base64 representation of MD5 digest)?br>

Name: common/class2.class

MD5-Digest: (base64 representation of MD5 digest)

数字签名是.SF签名文件的一个签名版本。这些是人类无法解译的二进制文件。数字签名文件和.SF文件的名称相同，但扩展名不同。数字签名的类型不同，其扩展名也各不相同，通常为RSA或DSA。

JAR目录

为优化类加载器在网络应用程序，特别是applet中的类搜索过程，因此引入了JAR目录（一般称作JarIndex机制）。JarIndex机制收集在一个applet中定义的所有JAR文件，并将信息存储在applet的类路径的第一个JAR文件的一个目录文件中。下载第一个JAR文件后，applet类加载器将收集内容信息，这样可提高JAR文件的下载效率。

系统对现有的JAR工具进行强化，使其能够检查一个JAR文件列表，并生成目录信息，说明哪些类和资源位于哪个JAR文件中。这些目录信息存储在根JAR文件META-INF目录中的一个名为INDEX.LIST的简单文本文件中。当类加载器加载根JAR文件时，它阅读INDEX.LIST文件，并用它建立一个由文件和数据包名称到JAR文件名列表的映射散列表。为了找到一个类或资源，类加载器查询散列表找到正确的JAR文件，如有必要，再下载这个文件。

提供服务

META-INF/services目录中的文件为服务提供程序配置文件。一个服务通常是一组著名的界面和（一般是抽象的）类。一个服务提供程序是一项服务的特殊执行过程。提供程序中的类往往执行上述界面并继承服务本身定义的类。

服务提供程序通过把一个提供程序配置文件放在META-INF/services源目录中来识别自己。这个文件名应由完全合格的抽象服务类名称构成。

应用这些特性

了解JAR文件的这些特性后，你就可以在实际开发工作中创造性的应用它们。如果你已经有了一些有趣的使用方法，请在文章的讨论部分分享你的经验

/bin：存放启动和关闭tomcat的脚本文件；
/conf：存放tomcat的各种配置文件，比如：server.xml
/server/lib：存放tomcat服务器所需要的各种jar文件（jar文件只可被tomcat 服务器访问）
/server/webapps：存放tomcat自带的两个web应用：admin应用和manager应用。
/common/lib：存放tomcat服务器以及所有web应用都可以访问的jar文件夹（web和tomcat服务器都可访问此jar）
/shared/lib：存放web都可访问的jar文件。（可以被所有的web访问，但不能被tomcat访问）
/logs：存放tomcat的日志文件
/webapps：当发布web应用时，默认情况下把web应用文件放于此目录下
/work：tomcat把由jsp生成的Servlet放于此目录
另：在web应用中，WEB-Inf目录下，也可以建立lib子目录，在此子目录下可以存放各种jar文件，这些jar文件只能被当前web应用访问。其中，在web-inf目录下的lib与classes目录，Tomcat类装载器先装载classes目录下的类，再装载lib目录下的类。因为类同名时，classes优先。

其中jsp运行时，查找class的顺序为：项目文件夹（WEB-INF\lib）===》容器文件夹（tomcat\common\lib）==》jdk文件夹（jdk\jre\lib\ext）

Tomcat的class加载的优先顺序一览
1.最先是$JAVA_HOME/jre/lib/ext/下的jar文件。
2.环境变量CLASSPATH中的jar和class文件。
3.$CATALINA_HOME/common/classes下的class文件。
4.$CATALINA_HOME/commons/endorsed下的jar文件。
5.$CATALINA_HOME/commons/i18n下的jar文件。
6.$CATALINA_HOME/common/lib 下的jar文件。
（JDBC驱动之类的jar文件可以放在这里，这样就可以避免在server.xml配置好数据源却出现找不到JDBC Driver的情况。）
7.$CATALINA_HOME/server/classes下的class文件。
8.$CATALINA_HOME/server/lib/下的jar文件。
9.$CATALINA_BASE/shared/classes 下的class文件。
10.$CATALINA_BASE/shared/lib下的jar文件。
11.各自具体的webapp /WEB-INF/classes下的class文件。
12.各自具体的webapp /WEB-INF/lib下的jar文件。

class的搜寻顺序如下
-------------
/WEB-INF/classes of your web application 
/WEB-INF/lib/*.jar of your web application 
$CATALINA_HOME/common/classes 
$CATALINA_HOME/common/endorsed/*.jar 
$CATALINA_HOME/common/i18n/*.jar 
$CATALINA_HOME/common/lib/*.jar 
$CATALINA_BASE/shared/classes 
$CATALINA_BASE/shared/lib/*.jar 
--------------
因此放在不同webapp里的class文件，会被classloader加载成不同的实例。
例如假设下面两个不同内容的class。分别放在不同的webapp的class目录下。
package com.lizongbo;
public class TestClass {
  private String NAME="lizongbo";
}

package com.lizongbo;
public class TestClass {
  private String NAME="li_zongbo";
}

在不同的webapp得到的com.lizongbo.NAME结果是不同的，且互不影响。
但是注意，以下包名开头的class例外：
javax.* 
org.xml.sax.* 
org.w3c.dom.* 
org.apache.xerces.* 
org.apache.xalan.* 

ps,注意.在各个jar中的\META-INF\MAINFEST.MF文件里Class-Path键值对，也会提供jar的加载优先顺序。
例如某jar的MAINFEST.MF内容如下：
Manifest-Version: 1.0
Created-By: lizongbo
Class-Path: commons-beanutils.jar
Class-Path: commons-collections.jar
Class-Path: commons-dbcp.jar
Class-Path: commons-digester.jar
Class-Path: commons-logging.jar
Class-Path: commons-pool.jar
Class-Path: commons-services.jar
Class-Path: commons-validator.jar
Class-Path: jakarta-oro.jar
Main-Class: com.lizongbo.MyTestClass


那么在加载这个jar的时候，会先在此jar所在目录下依次先加载commons-beanutils.jar，commons-collections.jar。。。等jar文件。

在不同的地方放置jar和class可能会产生意想不到的后果,，尤其是不同版本的jar文件，因此在实际应用部署web应用时候要特别留心.

例如 使用javamail常见的一个出错信息:
javax.mail.NoSuchProviderException: No provider for smtp
其真实原因就很可能如下:
在不同的加载jar的目录下放置了不同版本的mail.jar,比如一个是javamail1.3.1的mail.jar
在D:\jakarta-tomcat-5.5.8\common\lib下,而另外一个是javamail1.3.2的mail.jar在
D:\jakarta-tomcat-5.5.8\webapps\lizongbo\WEB-INF/lib下,
那么lizongbo这个webapp中使用到javamail进行邮件发送的时候，便会出现No provider for smtp的错误。

JSP 2 发布的同时增加了一些新的规则及语法，但多数服务器仍兼容运行 JSP 2 以前版本的程序，Tomcat 5.0.xx 为支持 JSP 2 及兼容 JSP 2 以前版本，在 /WEB-INF 目录下做了相应的配置，其具体方法简述如下：

/WEB-INF/web.xml 你的Web应用程序配置文件，这是一个XML文件，其中描述了 servlet 和其他的应用组件配置及命名规则；

/WEB-INF/classes/ 这个目录包含了站点所有用的 class 文件，包括 servlet class 和非servlet class，他们不能包含在 .jar文件中。

站点的类的存放规则应该按照Java的打包规则执行。例如： 有一个类命名为 com.mycompany.mypackage.MyServlet， 你应该按照以下形式部署： /WEB-INF/classes/com/mycompany/mypackage/MyServlet.class ；

 /WEB-INF/tags/ 标签文件库，存放了客户定义的标签文件，该目录并不一定为 tags，用户可以根据自己的喜好和习惯为自己的标签文件库命名，当使用了用户定义的标签文件库名称时，在用户使用标签文件时就必须声明正确的标签文件库路径。例如：当自定义标签文件库名称为 simpleTags 时，在使用 simpleTags 目录下的标签文件时，就必须在 jsp 文件头声明为：<%@ taglib prefix="tags" tagdir="/WEB-INF/simpleTags" % >；

/WEB-INF/jsp/ Jsp 1.2 以下版本的文件存放位置。改目录没有特定的声明，同样，用户可以根据自己的喜好与习惯来命名。此目录主要存放的是 Jsp 1.2 以下版本的文件，为区分 Jsp 2.0 文件，通常使用 jsp 命名，当然你也可以命名为 jspOldEdition ； ^_^ /WEB-INF/jsp2/ 与 jsp 文件目录相比，该目录下主要存放 Jsp 2.0 以下版本的文件，当然，它也是可以任意命名的，同样为区别 Jsp 1.2 以下版本的文件目录，通常才命名为 jsp2。

假设你已将Tomcat解压,你已得到下列目录结构:
    目录名--描述
    bin
    包含启动/关闭脚本
    conf
    包含不同的配置文件,

    包括 server.xml(Tomcat的主要配置文件)和为不同的Tomcat配置的web应用设置缺省值的文件web.xml
    doc
    包含各种Tomcat文档
    lib
    包含Tomcat使用的jar文件.unix平台此目录下的任何文件都被加到Tomcat的classpath中
    logs
    Tomcat摆放日志文件的地方
    src
    ServletAPI源文件.先别高兴,这些只有些必须在Servlet容器内实现的空接口和抽象类
    webapps
    包含web项目示例
   

此外你可以Tomcat会创建如下目录:
    work
    Tomcat自动生成,放置Tomcat运行时的临时文件(如编译后的JSP文件).如在Tomcat运行时删除此目录.JSP页面将不能运行.
    classes
    你可以创建此目录来添加一些附加的类到类路径中.任何你加到此目录中的类都可在Tomcat的类路径中找到自身.

---------------------------华丽的分割线---------------------   

Tomcat的配置文件

    Tomcat的配置基于两个配置文件:
    1.server.xml - Tomcat的全局配置文件
    2.web.xml - 在Tomcat中配置不同的关系环境

    server.xml
    server.xml是Tomcat的主配置文件.完成两个目标:

    1 提供Tomcat组件的初始配置.
    2 说明Tomcat的结构,含义,使得Tomcat通过实例化组件完成起动及构建自身, 如在server.xml所指定的

    server.xml种的重要元素:

    元素及其描述
    Server
    server.xml文件中最重要的元素.Server定义了一个Tomcat服务器.一般你不用对他担心太多.Server元素能包含Logger和ContextManager元素类型
    Logger
    此元素定义一个Logger对象,每个Logger都有一个名字去标识,也有一个纪录Logger的输出和冗余级别(描述此日志级别)和包含日志文件的路径.通常有servlet的Logger(ServletContext.log()处),JSP和Tomcat运行时的Logger。

    ContextManager
    ContextManager说明一套ContextInterceptor, RequestInterceptor , Context和他们的Connectors的配置及结构.ContextManager有几个随同提供的特性:
    1. 用来纪录调试信息的调试级别
    2. webapps/,conf/,logs/和所有已定义的环境的基本位置.用来使Tomcat可以在TOMCAT_HOME外的其他目录启动.
    3. 工作目录的名字

    ContextInterceptor&RequestInterceptor

    这些侦听器(interceptors)侦听具体发生在ContextManager中的事件.例如,ContextInterceptor侦听Tomcat的启动及终止事件,RequestInterceptor监视在它服务过程中用户请求需要通过的不同阶段.Tomcat的管理员不必知道太多关于侦听器的知识;另外,开发者应该知道这是如何在Tomcat中实现一个”全局”型的操作(例如安全性及每个请求日志)
    Connector
    Connector表示一个到用户的联接,不管是通过web服务器或直接到用户浏览器(在一个独立配置中).Connector负责管理Tomcat的工作线程和 读/写 连接到不同用户的端口的 请求/响应.Connector的配置包含如下信息:
    1.句柄类
    2.句柄监听的TCP/IP端口
    3.句柄服务器端口的TCP/IP的backlog.
    Context
    每个Context提供一个指向你放置你Web项目的Tomcat的下属目录。每个Context包含如下配置： [Page]
    1. Context放置的路径,可以是与ContextManager主目录相关的路径.
    2.纪录调试信息的调试级别
    3.可重载的标志.开发Servlet时,重载更改后的Servlet,这是一个非常便利的特性,你可以调试或用Tomcat测试新代码而不用停止或重新启动Tomcat.要打开重载,把reloadable设为真即可.这虽花费时间但可检测所发生的变化;更重要的事,鉴于,在一个装载类对象装入一个新的servlet时,类装载触发器可能会掷出一些错误.为避免这些问题,你可以设置可重载为假,这将停止重载功能.

    web.xml

    Tomcat可以让用户通过将缺省的web.xml放入conf目录中来定义所有关系环境的web.xml的缺省值.建立一个新的关系环境时,Tomcat使用缺省的web.xml文件作为基本设置和应用项目特定的web.xml(放在应用项目的WEB-INF/web.xml文件)来覆盖这些缺省值.