Today, when I tried to deploy the Docker-like server project, I encountered a small problem, which puzzled me for two or three hours. I feel that I should have encountered this problem before. Thanks to my habit of not recording the problem, I tortured myself for a while.

Problem description

The Test project deployed in Tomcat needs to be accessed without the project path. After the following two methods are tried, the project cannot be loaded when Tomcat starts.

  1. in/conf/server.xmlIn the<Host>Add to tag<Context>Tag (not recommended in the documentation).

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.

The configuration is as follows:

<Context path="" docBase="D: \ \ XXX UI - engine - 1.0.0.13. War"/>
Copy the code
  1. in/conf/Catalina/LocalhostImport an XML file under the path. The file name is customized according to the following table and the project access path you need. Add a band to the filedocBaseProperties of the<Context>The label.
<Context docBase="D: \ \ XXX UI - engine - 1.0.0.13. War"/>
Copy the code

path
path
server.xml
2

Problem analysis

After analysis, the reasons for this problem may be as follows:

  1. As can be seen from mark 1 in the figure above, when we remove the project access path, the project will become the default project of Tomcat (the default project corresponds to the ROOT folder in webapps).
  2. Freshly pulled from the containertomcatThe ROOT folder inside the image is not empty and contains some home page files. Although Tomcat will scan our customContextFile, but Tomcat will still directly load the existing ROOT project,autoDeployProperty did not play a role in updating files that changed in the project. The reasons may be as follows:

    According to the documentation, when we started Tomcat, it scanned our Context configuration file, but appBase(default: Webapps) already had a working directory for the ROOT project, so unzipping and replacing the file was skipped.

The solution

The above analysis may not be too clear, because I only guess the general document reading ability is not enough, many places do not want to read a long time, with the help of translation to read the general, details of the English or do not know what he is talking about, such as the automatic deployment of Tomcat expected behavior explanation.

Delete the conflict folder in webapps and have Tomcat decompress the target WAR package in the Context file at startup.