Tomcat是的JSWDK(JavaServer Web Development Kit)中的运行环境(servlet容器)。Tomcat的源代码被提供给Jakarta项目，在Open Source的模型下进行进一步的开发。Tomcat是一个Server容器，同样的，运行在EJB的容器中。
Tomcat是Apache-Jarkarta的一个子项目,是一个开放式原码,免费支持和Servlet技术的容器,它同时又是一个服务器软件.
Tomcat很受广大程序员的喜欢,因为它运行时占用的系统资源小,扩展性好,支持负载平衡与邮件服务等开发应用系统常用的功能,而且它还在不断的改进和完善中，任何一个感兴趣的程序员都可以更改它或在其中加入新的功能.
Tomcat是一个小型的轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP程序的首选.
如今，基于Web的应用越来越多，传统的Html已经满足不了如今的需求。我们需要一个交互式的Web，于是便诞生了各种Web语言。如
Asp，Jsp，Php等。当然，这些语言与传统的语言有着密切的联系，如Php基于C和C++语言，Jsp基于Java语言。Tomcat即是一个
Jsp和Servlet的运行平台。
Tomcat是一个免费的开源的Serlvet容器，它是Apache基金会的Jakarta项目中
的一个核心项目，由Apache，Sun和其它一些公司及个人共同开发而成。由于有了Sun的参与和支持，最新的Servlet和Jsp规范总能在
Tomcat中得到体现。Tomcat被JavaWorld杂志的编辑选为2001年度最具创新的java产品，可见其在业界的地位。
Tomcat最新版本是4.0x.4.0x与3.x的架构不同，而是重新设计的。Tomcat4.0x中采用了新的Servlet容器：Catalina，完整的实现了Servlet2.3和Jsp1.2规范。Tomcat提供了各种平台的版本供下载，可以从
与
传统的桌面应用程序不同，Tomcat中的应用程序是一个WAR（WebArchive）文件。WAR是Sun提出的一种Web应用程序格式，与JAR类
似，也是许多文件的一个压缩包。这个包中的文件按一定目录结构来组织：通常其根目录下包含有Html和Jsp文件或者包含这两种文件的目录，另外还会有一
个WEB-INF目录，这个目录很重要。通常在WEB-INF目录下有一个web.xml文件和一个classes目录，web.xml是这个应用的配置
文件，而classes目录下则包含编译好的Servlet类和Jsp或Servlet所依赖的其它类（如JavaBean）。通常这些所依赖的类也可以
打包成JAR放到WEB-INF下的lib目录下，当然也可以放到系统的CLASSPATH中，但那样移植和管理起来不方便。
在
Tomcat中，应用程序的部署很简单，你只需将你的WAR放到Tomcat的webapp目录下，Tomcat会自动检测到这个文件，并将其解压。你在
浏览器中访问这个应用的Jsp时，通常第一次会很慢，因为Tomcat要将Jsp转化为Servlet文件，然后编译。编译以后，访问将会很快。另外
Tomcat也提供了一个应用：manager，访问这个应用需要用户名和密码，用户名和密码存储在一个xml文件中。通过这个应用，辅助于Ftp，你可
以在远程通过Web部署和撤销应用。当然本地也可以。
Tomcat不仅仅是一个Servlet容器，它也具有传统的Web服务器的功能：
处理Html页面。但是与Apache相比，它的处理静态Html的能力就不如Apache.我们可以将Tomcat和Apache集成到一块，让
Apache处理静态Html，而Tomcat处理Jsp和Servlet.这种集成只需要修改一下Apache和Tomcat的配置文件即可。
另
外，Tomcat提供Realm支持。Realm类似于Unix里面的group.在Unix中，一个group对应着系统的一定资源，某个group不
能访问不属于它的资源。Tomcat用Realm来对不同的应用（类似系统资源）赋给不同的用户（类似group）。没有权限的用户则不能访问这个应用。
Tomcat提供三种Realm，1：JDBCRealm，这个Realm将用户信息存在数据库里，通过JDBC获得用户信息来进行验证。
2：JNDIRealm，用户信息存在基于LDAP的服务器里，通过JNDI获取用户信息。3：MemoryRealm，用户信息存在一个xml文件里
面，上面讲的manager应用验证用户时即使用此种Realm.通过Realm我们可以方便地对访问某个应用的客户进行验证。
在
Tomcat4中，你还可以利用Servlet2.3提供的事件监听器功能，来对你的应用或者Session实行监听。Tomcat也提供其它的一些特
征，如与SSL集成到一块，实现安全传输。还有Tomcat也提供JNDI支持，这与那些J2EE应用服务器提供的是一致的。说到这里我们要介绍一下通常
所说的应用服务器（如WebLogic）与Tomcat有何区别。应用服务器提供更多的J2EE特征，如EJB，JMS，JAAS等，同时也支持Jsp和
Servlet.而Tomcat则功能没有那么强大，它不提供EJB等支持。但如果与JBoss（一个开源的应用服务器）集成到一块，则可以实现J2EE
的全部功能。既然应用服务器具有Tomcat的功能，那么Tomcat有没有存在的必要呢？事实上，我们的很多中小应用不需要采用EJB等技术，Jsp和
Servlet已经足够，这时如果用应用服务器就有些浪费了。而Tomcat短小精悍，配置方便，能满足我们的需求，这种情况下我们自然会选择
Tomcat.
基于Tomcat的开发其实主要是Jsp和Servlet的开发，开发Jsp和Servlet非常简单，你可以用普通的文
本编辑器或者IDE，然后将其打包成WAR即可。我们这里要提到另外一个工具Ant，Ant也是Jakarta中的一个子项目，它所实现的功能类似于
Unix中的make.你需要写一个build.xml文件，然后运行Ant就可以完成xml文件中定义的工作，这个工具对于一个大的应用来说非常好，我
们只需在xml中写很少的东西就可以将其编译并打包成WAR.事实上，在很多应用服务器的发布中都包含了Ant.另外，在Jsp1.2中，可以利用标签库
实现Java代码与Html文件的分离，使Jsp的维护更方便。
Tomcat也可以与其它一些软件集成起来实现更多的功能。如与上面提到的JBoss集成起来开发EJB，与Cocoon（Apache的另外一个项目）集成起来开发基于Xml的应用，与OpenJMS
集成起来开发JMS应用，除了我们提到的这几种，可以与Tomcat集成的软件还有很多。
Tomcat确实是一个很好的工具，不仅仅因为其免费，功能强大，更因为其开放性。如今，开源软件越来越收到人们的重视，Linux就是一个成功的典型。
首先我们先介绍一下为什么要让 Apache 与 Tomcat 之间进行连接。事实上 Tomcat 本身已经提供了 HTTP
服务，该服务默认的端口是 8080，装好 tomcat 后通过 8080 端口可以直接使用 Tomcat 所运行的应用程序，你也可以将该端口改为
80。
既然 Tomcat 本身已经可以提供这样的服务，我们为什么还要引入 Apache 或者其他的一些专门的 HTTP 服务器呢？原因有下面几个：
1. 提升对静态文件的处理性能
2. 利用 Web 服务器来做负载均衡以及容错
3. 无缝的升级应用程序
这三点对一个 web 网站来说是非常之重要的，我们希望我们的网站不仅是速度快，而且要稳定，不能因为某个 Tomcat
宕机或者是升级程序导致用户访问不了，而能完成这几个功能的、最好的 HTTP 服务器也就只有 apache 的 http server 了，它跟
tomcat 的结合是最紧密和可靠的。
接下来我们介绍三种方法将 apache 和 tomcat 整合在一起。
这是最常见的方式，你可以在网上找到很多关于配置JK的网页，当然最全的还是其官方所提供的文档。JK 本身有两个版本分别是 1 和 2，目前 1 最新的版本是 1.2.19，而版本 2 早已经废弃了，以后不再有新版本的推出了，所以建议你采用版本 1。
JK 是通过 AJP 协议与 Tomcat 服务器进行通讯的，Tomcat 默认的 AJP Connector 的端口是
8009。JK 本身提供了一个监控以及管理的页面 jkstatus，通过 jkstatus 可以监控 JK 目前的工作状态以及对到 tomcat
的连接进行设置，如下图所示：
在这个图中我们可以看到当前JK配了两个连接分别到 8109 和 8209 端口上，目前 s2 这个连接是停止状态，而 s1
这个连接自上次重启后已经处理了 47 万多个请求，流量达到 6.2 个 G，最大的并发数有 13 等等。我们也可以利用 jkstatus
的管理功能来切换 JK 到不同的 Tomcat 上，例如将 s2 启用，并停用
s1，这个在更新应用程序的时候非常有用，而且整个切换过程对用户来说是透明的，也就达到了无缝升级的目的。关于 JK
的配置文章网上已经非常多了，这里我们不再详细的介绍整个配置过程，但我要讲一下配置的思路，只要明白了配置的思路，JK 就是一个非常灵活的组件。
JK 的配置最关键的有三个文件，分别是
httpd.conf
Apache 服务器的配置文件，用来加载 JK 模块以及指定 JK 配置文件信息
workers.properties
到 Tomcat 服务器的连接定义文件
uriworkermap.properties
URI 映射文件，用来指定哪些 URL 由 Tomcat 处理，你也可以直接在 httpd.conf 中配置这些 URI，但是独立这些配置的好处是 JK 模块会定期更新该文件的内容，使得我们修改配置的时候无需重新启动 Apache 服务器。
其中第二、三个配置文件名都可以自定义。下面是一个典型的 httpd.conf 对 JK 的配置
# (httpd.conf)
# 加载 mod_jk 模块
LoadModule jk_module modules/mod_jk.so
#
# Configure mod_jk
#
JkWorkersFile conf/workers.properties
JkMountFile conf/uriworkermap.properties
JkLogFile logs/mod_jk.log
JkLogLevel warn
|
接下来我们在 Apache 的 conf 目录下新建两个文件分别是 workers.properties、uriworkermap.properties。这两个文件的内容大概如下
#
# workers.properties
#
# list the workers by name
worker.list=DLOG4J, status
# localhost server 1
# ------------------------
worker.s1.port=8109
worker.s1.host=localhost
worker.s1.type=ajp13
# localhost server 2
# ------------------------
worker.s2.port=8209
worker.s2.host=localhost
worker.s2.type=ajp13
worker.s2.stopped=1
worker.DLOG4J.type=lb
worker.retries=3
worker.DLOG4J.balanced_workers=s1, s2
worker.DLOG4J.sticky_session=1
worker.status.type=status
|
以上的 workers.properties 配置就是我们前面那个屏幕抓图的页面所用的配置。首先我们配置了两个类型为 ajp13 的
worker 分别是 s1 和 s2，它们指向同一台服务器上运行在两个不同端口 8109 和 8209 的 Tomcat
上。接下来我们配置了一个类型为 lb（也就是负载均衡的意思）的 worker，它的名字是 DLOG4J，这是一个逻辑的
worker，它用来管理前面配置的两个物理连接 s1 和 s2。最后还配置了一个类型为 status 的 worker，这是用来监控 JK
本身的模块。有了这三个 worker 还不够，我们还需要告诉 JK，哪些 worker 是可用的，所以就有 worker.list = DLOG4J, status 这行配置。
接下来便是 URI 的映射配置了，我们需要指定哪些链接是由 Tomcat 处理的，哪些是由 Apache 直接处理的，看看下面这个文件你就能明白其中配置的意义
/*=DLOG4J
/jkstatus=status
!/*.gif=DLOG4J
!/*.jpg=DLOG4J
!/*.png=DLOG4J
!/*.css=DLOG4J
!/*.js=DLOG4J
!/*.htm=DLOG4J
!/*.html=DLOG4J
|
相信你已经明白了一大半了：所有的请求都由 DLOG4J 这个 worker 进行处理，但是有几个例外，/jkstatus 请求由
status 这个 worker 处理。另外这个配置中每一行数据前面的感叹号是什么意思呢？感叹号表示接下来的 URI 不要由 JK
进行处理，也就是 Apache 直接处理所有的图片、css 文件、js 文件以及静态 html 文本文件。
通过对 workers.properties 和 uriworkermap.properties 的配置，可以有各种各样的组合来满足我们前面提出对一个 web 网站的要求。您不妨动手试试！
回页首
这是利用 Apache 自带的 mod_proxy 模块使用代理技术来连接 Tomcat。在配置之前请确保是否使用的是 2.2.x 版本的 Apache 服务器。因为 2.2.x 版本对这个模块进行了重写，大大的增强了其功能和稳定性。
http_proxy 模式是基于 HTTP 协议的代理，因此它要求 Tomcat 必须提供 HTTP 服务，也就是说必须启用 Tomcat 的 HTTP Connector。一个最简单的配置如下
ProxyPass /images !
ProxyPass /css !
ProxyPass /js !
ProxyPass /
|
在这个配置中，我们把所有 的请求代理到 ，这也就是
Tomcat 的访问地址，除了 images、css、js 几个目录除外。我们同样可以利用 mod_proxy 来做负载均衡，再看看下面这个配置
ProxyPass /images !
ProxyPass /css !
ProxyPass /js !
ProxyPass / balancer://example/
BalancerMember
BalancerMember
BalancerMember
|
配置比 JK 简单多了，而且它也可以通过一个页面来监控集群运行的状态，并做一些简单的维护设置。
回页首
ajp_proxy 连接方式其实跟 http_proxy 方式一样，都是由 mod_proxy 所提供的功能。配置也是一样，只需要把
http:// 换成 ajp:// ，同时连接的是 Tomcat 的 AJP Connector 所在的端口。上面例子的配置可以改为：
ProxyPass /images !
ProxyPass /css !
ProxyPass /js !
ProxyPass / balancer://example/
BalancerMember ajp://server1:8080/
BalancerMember ajp://server2:8080/
BalancerMember ajp://server3:8080/
|
采用 proxy 的连接方式，需要在 Apache 上加载所需的模块，mod_proxy 相关的模块有
mod_proxy.so、mod_proxy_connect.so、mod_proxy_http.so、mod_proxy_ftp.so、
mod_proxy_ajp.so， 其中 mod_proxy_ajp.so 只在 Apache 2.2.x 中才有。如果是采用
http_proxy 方式则需要加载 mod_proxy.so 和 mod_proxy_http.so；如果是 ajp_proxy 则需要加载
mod_proxy.so 和 mod_proxy_ajp.so这两个模块。
回页首
相对于 JK 的连接方式，后两种在配置上是比较简单的，灵活性方面也一点都不逊色。但就稳定性而言就不像 JK 这样久经考验，毕竟
Apache 2.2.3 推出的时间并不长，采用这种连接方式的网站还不多，因此，如果是应用于关键的互联网网站，还是建议采用 JK 的连接方式。
在做远程调试时，在windows系统和非windows系统下的配置，Tomcat中会有所差别,具体如下：
第一步、配置tomcat
一、在windows系统中：
打开%CATALINE_HOME%/bin下的文件catalina.bat，加入下面这行：
set CATALINA_OPTS=-server -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8787
其中address=8787是没被使用的端口号。连接方式有两种，为dt_shmem和dt_socket，分别表示本机调试和远程调试。
二、在非windows系统中：
还需要把% CATALINE_HOME %/bin/startup.sh中的最后一行exec
"$PRGDIR"/"$EXECUTABLE" start "$@" 中的start改成jpda
start。由于默认的端口是8000，所以如果8000端口已有他用的话，还需在catalina.sh文件中设
置：JPDA_ADDRESS=8787。
输入命令startup.sh或者catalina.sh jpda start就可启动tomcat。
第二步、配置eclipse
在Eclipse中选择RunDebug，在弹出的对话框中右击Remote Java Application新建一个远程调试项，如下如所示：
在“Name”输入框中输入远程调试的名称，在“Project”中选择要调试的项目，在“Host”中输入需要远程调试项目的IP，也就是
tomcat所在的IP，在“Port”中输入设置的端口号，比如上面设置的8787，然后钩选“Allow termination of
remote VM”，点击“Apply”即可。
设置完后就可以开始调试了，大概分一下几步：
1、启动tomcat（远程），如在控制台输出“Listening for transport dt_socket at address: 8787”，即说明在tomcat中设置成功；
2、在本机设置断点，即在需要监视的代码行前双击就会出现一个小圆点；
3、进入上图界面，选择要调试的项，点击“Debug”即可进行远程调试；
4、当运行到设置了断点的代码行处即可看到如下图所示的浅绿条。
按键操作：
1、F5键与F6键均为单步调试，F5是进入本行代码中执行，F6是执行本行代码，跳到下一行；
2、F7是跳出函数；
3、F8是执行到最后。
当然，为了方便，可以新建一个批处理文件，假如取名为debug.bat，在这个文件中加入下面几行：
cd %CATALINE_HOME%/bin
set JPDA_ADDRESS=8787
set JPDA_TRANSPORT=dt_socket
set CATALINA_OPTS=-server -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8787
startup
这样需要远程调试时，运行debug.bat即可；不需要远程调试时，还是运行startup.bat文件。
其中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的错误
