Tomcat 8 权威指南
一、关键词
Servlet 容器；
$CATALINA_HOME，Tomcat 安装的根目录；
/conf/ =>server.xml 容器的主配置文件;
/webapps/ => 存放 Web 应用的相关文件;
修改tomcat配置文件后 需重启生效；
二、容器安装
http://wiki.jikexueyuan.com/project/tomcat/setup.html
三、应用部署
1、两种方式
- 静态部署。在启动 Tomcat 之前安装 Web 应用。
- 动态部署。使用 Tomcat 的 Manager 应用直接操控已经部署好的 Web 应用（依赖 auto-deployment 特性），可与ant,maven。
2、上下文（context）概念
上下文在 Tomcat 中其实就是 Web 应用;
上下文描述符文件（ Context Descriptor） 位置：
a.$CATALINA_BASE/conf/[enginename]/[hostname]/[webappname].xml
b.$CATALINA_BASE/webapps/[webappname]/META-INF/context.xml
在目录 1 中的文件名为 [webappname].xml，但在目录 2 中，文件名为 context.xml。如果某个 Web 应用没有相应的上下文描述符文件，Tomcat 就会使用默认值配置该应用。
3、静态部署（启动时部署，先部署后启动）
应用部署的位置由 appBase 目录属性（server.xml里面配置）来决定，默认的 appBase 属性所指定的目录为 $CATALINA_BASE/webapps；
既可以放入未经压缩的 Web 应用资源文件（通常被称为 exploded web application，“膨胀 Web 应用”），也可以放置已压缩过的 Web 应用资源文件（.WAR 文件）；
只有当主机的 deployOnStartup 属性为 true, 应用才会在 Tomcat 启动时进行自动部署。
在以上情况下，当 Tomcat 启动时，部署的具体步骤如下：
- 先部署上下文描述符文件。
- 然后再对没被任何上下文描述符文件引用过的膨胀 Web 应用进行部署。 如果在
appBase中已存在与这种应用有关的 .WAR 文件，而且要比膨胀应用文件更新，那么就会将膨胀应用的文件夹清除，转而从 .WAR 文件中部署 Web 应用。 - 部署 .WAR 文件。
4、动态部署（热加载，无需重启）
如果主机的 autoDeploy 属性为 true，主机就会在必要时（放入WAR包）尝试着动态部署并更新 Web 应用；
当 autoDeploy 设置为 true 时，运行中的 Tomcat 服务器能够允许实现以下行为：
- 对放入主机
appBase指定目录下的 .WAR 文件进行配置。 - 对放入主机的膨胀 Web 应用进行配置。
- 对于已通过 .WAR 文件配置好的应用，如果又提供了更新的 .WAR 文件，则使用新 .WAR 文件对该应用重新进行配置。在这种情况下，会先移除原有的膨胀 Web 应用，然后再次对 .WAR 文件进行扩展（膨胀）。注意，如果在主机配置中，没有把
unpackWARs属性设为false，则 WAR 文件将不会膨胀，这时 Web 应用将部署为一个压缩文档。 - 如果
/WEB-INF/web.xml文件（或者任何其他被定义为 WatchedResource 的资源）更新，则重新加载 Web 应用。 - 如果用来部署 Web 应用的上下文描述符更新，则重新部署该 Web 应用。
- 如果 Web 应用所使用的全局或者每台主机中的上下文描述符已更新，则重新部署与该应用有依赖关系的 Web 应用。
- 如果一个上下文描述符被添加到
$CATALINA_BASE/conf/[enginename]/[hostname]/目录中，并且该描述文件带有与之前部署的 Web 应用的上下文路径相对应的文件名，则重新部署该 Web 应用。 - 如果某个 Web 应用的文档库（docBase）被删除，则取消对该应用的部署。注意，在 Windows 系统下，要想实现这样的行为，必须开启防锁死功能（参看 Context 配置文档），否则无法删除运行中的 Web 应用的资源文件。
- 注意，也可以在加载器中对 Web 应用的重新加载进行配置，在这种情况下，会跟踪已加载的类所产生的更改。
$CATALINA_HOME/conf/web.xml 中被全局声明; 一些可配置的属性：
input |
在读取用于服务的资源时的输入缓冲大小（以字节计）。默认为 2048。 |
output |
在修改用于服务的资源时的输出缓冲大小（以字节计）。默认为 2048。 |
readonly |
上下文是否为“只读”，从而拒绝执行 PUT 或 DELETE 这样的 HTTP 命令。默认为 true。 |
fileEncoding |
文件编码用于读取静态资源时。默认取平台默认值。 |
$JAVA_HOME/jre/lib/ext）里 JAR 文件中的类。 * System 这种类加载器通常是根据 CLASSPATH 环境变量内容进行初始化的。标准的 Tomcat 启动脚本（$CATALINA_HOME/bin/catalina.sh 或 %CATALINA_HOME%incatalina.bat）完全忽略了 CLASSPATH 环境变量自身的内容，相反从下列仓库来构建系统类加载器：$CATALINA_HOME/bin/bootstrap.jar，$CATALINA_BASE/bin/tomcat-juli.jar 或 $CATALINA_HOME/bin/tomcat-juli.jar 日志实现类，$CATALINA_HOME/bin/commons-daemon.jar *Common 这种类加载器包含更多的额外类，它们对于Tomcat 内部类以及所有 Web 应用都是可见的，该类加载器所搜索的位置定义在 $CATALINA_BASE/conf/catalina.properties 的 common.loader 属性中。默认的设置会搜索下列位置（按照列表中的上下顺序）：
$CATALINA_BASE/lib中的解包的类和资源。$CATALINA_BASE/lib中的 JAR 文件。$CATALINA_HOME/lib中的解包类和资源。-
$CATALINA_HOME/lib中的 JAR 文件。
*WebappX 为每个部署在单个 Tomcat 实例中的 Web 应用创建的类加载器。你的 Web 应用的 /WEB-INF/classes 目录中所有的解包类及资源，以及 /WEB-INF/lib 目录下 JAR 文件中的所有类及资源，对于该应用而言都是可见的，但对于其他应用来说则不可见。
Web 应用类加载器背离了默认的 Java 委托模式（父类加载机制），当某个请求想从 Web 应用的 WebappX 类加载器中加载类时，该类加载器会先查看自己的仓库，而不是预先进行委托处理。。JRE 基类的部分类不能被重写。
从 Web 应用的角度来看，加载类或资源时，要查看的仓库及其顺序如下：
- JVM 的 Bootstrap 类
- Web 应用的
/WEB-INF/classes类 - Web 应用的
/WEB-INF/lib/*.jar类 - System 类加载器的类（如上所述）
- Common 类加载器的类（如上所述）
如果 Web 应用类加载器配置有 <Loader delegate="true"/>，则顺序变为：
- JVM 的 Bootstrap 类
- System 类加载器的类（如上所述）
- Common 类加载器的类（如上所述）
- Web 应用的
/WEB-INF/classes类 - Web 应用的
/WEB-INF/lib/*.jar类