Tomcat修改项目访问路径配置后，无法加载项目的问题

今天在尝试将docker化的服务端项目部署到时碰到的一个小问题，困扰了我两三个小时，感觉之前应该也遇到过该问题，拜自己没有记录问题的习惯所赐，又折磨了自己一阵。

问题描述

在Tomcat中部署的Test项目需要在访问时去掉项目路径，尝试以下以下两种方式实现后，均导致Tomcat在启动时无法加载该项目。

1. 在/conf/server.xml中的<Host>标签中加入<Context>标签(文档中不推荐该方式)。

It is NOT recommended to place elements directly in the server.xml file. This is because it makes modifying the Context configuration more invasive since the main conf/server.xml file cannot be reloaded without restarting Tomcat.

配置如下：

<Context path="" docBase="D:\XXX\ui-engine-1.0.0.13.war"/>

2. 在/conf/Catalina/Localhost路径下引入一个xml文件，文件名称根据下表结合自己需要的项目访问路径自定义，在该文件中添加一个带docBase属性的<Context>标签。

<Context docBase="D:\XXX\ui-engine-1.0.0.13.war"/>

该文件中不能定义path属性，path属性只能在server.xml中使用，参照下图中标注2。

问题分析

这个问题出现的原因经过分析可能有以下几点：

1. 从上图标注1可以看出，当我们将项目访问路径去掉之后，该项目会成为Tomcat的默认项目（默认项目对应webapps中的ROOT文件夹）。
2. 容器内新拉取的tomcat镜像内的ROOT文件夹内不是空的，包含一些主页文件。尽管Tomcat会扫描到我们自定义的Context文件，但Tomcat启动时还是会直接加载已存在的该ROOT项目，autoDeploy属性未能起到更新该项目中变化的文件的作用。原因可能如下图：

   

   根据文档描述，当我们启动tomcat时，它扫描到我们的Context配置文件，但appBase(默认值为webapps)下已经存在了该ROOT项目对应的工作目录，所以就跳过了解压和替换文件这一操作。

解决方案

上面的分析可能写得不是太明白，因为我也只猜了个大概，文档阅读能力还是不太够，好多地方一长就不想看了，借助翻译大致看一遍，细节地方看英文还是不知道他在讲啥，比如Tomcat的自动部署的预期行为解释。

解决方案经过多次验证其实很简单，删除webapps下冲突的文件夹，让Tomcat在启动时自动解压Context文件中指定的目标war包，算是手动帮Tomcat标识文件变化吧。