在Web应用开发完毕后，一些项目有时候采用目录部署的形式，而且是在server.xml中增加Context配置的形式，例如下面这种形式：
<Context path="/test" docBase="/home/abc/test"/>
但是官方并不鼓励这样配置，可以通过两种在外部文件配置的形式，不影响Tomcat主配置来实现同样的效果。
$CATALINA_BASE/conf/[enginename]/[hostname]/[webappname].xml
$CATALINA_BASE/webapps/[webappname]/META-INF/context.xml
前面曾写过Tomcat的应用部署(WEB应用是怎么被部署的?，如何在Tomcat中部署应用的多个版本)，当时没有详细介绍context.xml。
关于上面提到的这两种形式，内容一样，只是在不同的位置进行配置，例如上面在server.xml中配置的内容，可以在创建一个名为test.xml的文件，将其存放在Tomcat的conf/localhost/test.xml，即上面两项的第一种情况，这里注意应用的名称会直接使用文件名，path的配置会被忽略。
严格来说，第二种并不能直接替换前面server.xml里的情况，所能解决的是对于webapps目录内部署应用的额外配置，例如manager这个应用，要增加远程访问限制(为什么你的Manager登录不成功?），就是通过第二种，在META-INF目录内增加context.xml来实现的。
而实质上这两种统一称为Context的描述文件(Context Descriptor)。这些描述文件里包含一些应用对于Context的特定配置，例如配置Session Manager，指定naming Resrouce，定义SessionCookie名称等。使用描述文件，相当于给Context做了自定义，没提供描述文件的应用，Tomcat就会直接使用默认值初始化应用。
而且还有一点，使用描述文件定义的应用，会先部署。
下面来看源代码
源码
在HostConfig中，所有的部署从这儿开始。
protected void deployApps() {File appBase = host.getAppBaseFile();File configBase = host.getConfigBaseFile();String[] filteredAppPaths = filterAppPaths(appBase.list());// Deploy XML descriptors from configBase deployDescriptors(configBase, configBase.list());// Deploy WARs deployWARs(appBase, filteredAppPaths);// Deploy expanded folders deployDirectories(appBase, filteredAppPaths);}
我们看到部署顺序：
部署XML描述文件
部署WAR应用
部署解压的Web应用
其中读取应用的目录就是各个Host对应的appBase对应的配置，我们常用的webapps目录是虚拟主机localhost默认对应的位置。
部署描述符,即第一种webappname.xml的时候，会从configBase中遍历所有以xml描述文件，然后部署之。
for (int i = 0; i < files.length; i++) {File contextXml = new File(configBase, files[i]);if (files[i].toLowerCase(Locale.ENGLISH).endsWith(".xml")) {ContextName cn = new ContextName(files[i], true);// 看这里if (isServiced(cn.getName()) || deploymentExists(cn.getName()))continue;results.add(es.submit(new DeployDescriptor(this, cn, contextXml)));}}for (Future<?> result : results) {try {result.get();} catch (Exception e) {log.error(sm.getString("hostConfig.deployDescriptor.threaded.error"), e);}}
其中注意ContextName生成那行代码，是直接使用了文件名进行Context的设置，ContextName我们前面文章看过源代码，这里配置的就是path，即实际请求的应用名称。
然后实际部署时，先通过Digester解析文件获取Context对象，再进行属性配置，之后的部署流程和其它的一致。
在StandardContext的初始化流程中，会判断获取之前设置的configFile对象，不为空会解析文件内容。
而我们上面的第二种方式：为应用提供context.xml，在Tomcat代码内，称之为ApplicationContextXml。
这个文件是在第二和第三个部署的时候，解析META-INF目录下是否包含context.xml，然后设置Context的configFile属性。初始化Context的时候，会有如下逻辑
if (context.getConfigFile() != null) {processContextConfig(digester, context.getConfigFile());}
这个就是前面webappname.xml解析时设置configFile之后走的流程，在ContextConfig中。Digester的解析请看前面的文章：Tomcat配置文件解析与Digester
这样一来，我们的自定义配置文件就在Tomcat中生效了。
关注Tomcat那些事儿，发现更多精彩文章！了解各种常见问题背后的原理与答案。深入源码，分析细节，内容原创，欢迎关注。
