为什么tomcat在重新部署时会替换context.xml？答案

【问题标题】：Why does tomcat replace context.xml on redeploy?为什么tomcat在重新部署时会替换context.xml？
【发布时间】：2011-05-01 06:32:30
【问题描述】：

文档说明您是否在此处有上下文文件：

$CATALINA_HOME/conf/Catalina/localhost/myapp.xml

这里不会被上下文文件替换：

mywebapp.war/META-INF/context.xml

写在这里：http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

仅当 $CATALINA_BASE/conf/[enginename]/[hostname]/ 中不存在应用程序的上下文文件时，应用程序文件内 /META-INF/context.xml 的单个文件中。

但是每次我重新部署战争时，它都会用 /META-INF/context.xml 替换这个 myapp.xml！

为什么会这样，我该如何避免？

感谢

【问题讨论】：

您是手动部署还是通过 IDE 插件部署？
就个人而言，我不会将 context.xml 放在应用服务器上。我不这样做，因为我很少依赖访问该文件。我通常将它保存在我的 WAR 文件中。
我通过将 mywebapp.war 放入 $CATALINA_HOME/webapps 来手动部署。我将默认设置保留在 WAR 中，但我希望能够在不修改战争本身的情况下按实例更改这些设置 - 这就是为什么我希望 conf 目录中的上下文保持不变
在邮件列表中查看这个最近的链mail-archive.com/users@tomcat.apache.org/msg81854.html
最近也在旧金山serverfault.com/questions/192784/…

标签： deployment tomcat tomcat6

【解决方案1】：

重新部署的取消部署部分删除应用程序和关联的 context.xml。

如果您使用 maven tomcat 插件，如果您使用以下命令部署应用程序，则可以避免删除 context.xml：

mvn tomcat:deploy-only -Dmaven.tomcat.update=true

您也可以使用带参数模式的 deploy-only 来部署 context.xml。

【讨论】：

对于在家跟随的人们：mvn tomcat7:deploy-only -Dmaven.tomcat.update=true -Dmaven.tomcat.mode=both -Dmaven.tomcat.contextFile=/foo/context.xml 可以解决问题。悲伤...但在tomcat7中有效。

【解决方案2】：

简短回答：

只需将 TOMCATHOME/conf/Catalina/localhost 目录设为只读，并继续阅读以了解更多详细信息：

对于快速部署模式（Eclipse动态web项目，直接Tomcat 连接等）在本地/非共享 Tomcat 服务器上，您只需定义 JDBC 数据源（或任何其他“网络资源”）使用 META-INF/context.xml 文件内 WAR 文件。在您的本地环境中轻松快速，但不适合暂存、QA 或生产。
对于构建部署模式（通常用于 staging、QA 或 prod），JDBC 数据源和其他“网络资源”详细信息由 QA/生产团队，不再是开发团队。因此，他们必须在 Tomcat 服务器中指定，而不是在 WAR 文件中了。在这种情况下，请在文件中指定它们 TOMCATHOME/conf/Catalina/localhost/CONTEXT.xml（更改Catalina 由引擎，localhost 由主机，CONTEXT 由您的上下文相应）。然而， Tomcat 将在每次部署时删除此文件。为了防止这种情况删除，只需将此目录设为只读即可；在 Linux 中，您可以键入：
```
   chmod a-w TOMCATHOME/conf/Catalina/localhost
```
瞧！欢迎您。

长答案

由于历史原因，Tomcat 允许您以四种方式定义 Web 资源（JDBC 数据源和其他）如果您碰巧多次定义相同的资源，则以非常特定的优先顺序在不同的地方（读取四个不同的文件）。中命名的那些上面的简短答案现在更适合每种用途，尽管您仍然可以使用其他人（不......你可能不想）。我不打算除非有人要求，否则在这里讨论其他的。

【讨论】：

当为 tomcat 开启自动部署并且你使用 tomcat7:undeploy 时这将不起作用，它会抱怨它无法删除上下文描述符文件
使用此选项，由于乍得评论中提到的原因，我的部署失败并显示错误消息 Cannot invoke Tomcat manager: Connection reset。相反，我使用了选项，使用来自 WEB-INF 的 context.xml 和来自 server.xml 的可选（外部）jndi 资源，如第一个答案here 中所述

【解决方案3】：

在 tomcat7 上，即使 autoDeploy=false，该文件也将在取消部署时被删除。这是记录在案的，而不是错误（尽管它避免了具有服务器端固定配置的良好自动化部署）。

我找到了解决我问题的解决方法：

在您的 webapp 中创建一个 META-INF/context.xml 文件，其中包含
在服务器上，在 server.xml 中创建第二个上下文“/config-context”，并将所有服务器端配置参数放在那里
在应用程序上使用 context.getContext("/config-context").getInitParameter(...) 来访问那里的配置。

这允许独立于已部署战争的每主机配置。

还应该可以通过添加诸如“/config-context-MYPATH”之类的上下文来添加每个上下文的配置。在您的应用中，您可以使用应用的上下文路径来计算配置应用的上下文路径。

【讨论】：

为什么核心 tomcat 开发人员对最佳实践部署如此无知？我基本上花了一个晚上才在这里找到解决方法，所有的解决方法都是反模式，但是 TC 开发人员否认并且不会承认这是在主机上安装 JNDI 属性和源代码的明智方法，而不是编译他们陷入了单片机和战争。 issues.apache.org/bugzilla/show_bug.cgi?id=34840

【解决方案4】：

根据文档 (http://tomcat.apache.org/tomcat-8.0-doc/config/automatic-deployment.html#Deleted_files)，在重新部署时，tomcat 会检测到您的应用程序的删除（取消部署）。所以它会开始一个清理过程，删除目录和 xml。这与自动部署无关 - 因此它也会在通过管理器重新部署和修改战争时发生。有 3 个例外：

永远不会删除全局资源
永远不会删除外部资源
如果 WAR 或 DIR 已被修改，则仅删除 XML 文件如果 copyXML 为真且 deployXML 为真

我不知道为什么，但是 copyXML="false" deployXML="false" 无济于事。

其次：将目录设置为只读只会使tomcat抛出异常并且不会启动。

您可以尝试将您的 $CATALINA_BASE/conf/Catalina/localhost/myapp-1.xml、$CATALINA_BASE/conf/Catalina/localhost/myapp-2.xml 等文件合并到 $CATALINA_BASE/conf/context.xml (仅当您确保您的应用程序不会部署自己的上下文配置时才有效，例如 myapp-1.xml)

如果有人能说出通常可以解决问题的“外部资源”是什么。

【讨论】：

【解决方案5】：

Re-deploy from war without deleting context 涵盖了标题所描述的一般问题，目前仍是一个未解决的问题。

在不删除上下文的重新部署和取消部署后删除上下文的部署之间存在公认的区别。文档已过期，管理器 GUI 仍不支持重新部署。

【讨论】：

【解决方案6】：

重新部署意味着两个部分：取消部署和部署。

取消部署会删除conf/Catalina/yourhost/yourapp.xml，因为

 <Host name="localhost" appBase="webapps" unpackWARs="true" 

           autoDeploy="true">      <!-- means autoUndeploy too!!! -->

 </Host>

更改autoDeploy="false"，Tomcat 没有命令删除conf/Catalina/yourhost/yourapp.xml。

有一项功能允许我们将这些步骤（取消部署/部署）作为一个步骤（重新部署）进行，而不会删除context.xml。此功能可通过 manager-text-interface 获得，但该选项在 manager-html-interface 中不可用。您可能必须等到bug in tomcat 修复。您可以使用此答案中描述的方法作为解决方法。

【讨论】：

取消部署会删除上下文。重新部署一定不能删除上下文，因为它与逻辑上取消部署应用程序无关，因为这不是单词所反映的操作意图。不幸的是，这种区别没有明确。简单来说，重新部署是一个有其含义的词。
@user250343 已更改答案，请检查。