我们的项目使用Cruise Control以.war文件的形式将Web应用程序构建和热部署到运行Tomcat的远程服务器(通过FTP)上(通过FTP)。不幸的是，"热"部署似乎无法正常工作，从而导致我们为响应每个部署而重启了Tomcat。我们真的很想自动神奇地做到这一点，就像构建本身一样。是否有捷径可寻？

旁注：两台机器都运行Windows(我认为是XP或者服务器)。

旁注2：性能并不重要。这是一个集成框。

解决方案

如果我们有定期计划的构建，则可以轻松地在cron中放入类似这样的内容

crontab -e

然后在凌晨1:30停下tomcat

30 1 * * * ./path_to_tamcat/bin/catalina.sh stop

然后在2分钟后重新启动

32 1 * * * ./path_to_tamcat/bin/catalina.sh start

当然，这对于非常规部署不是最好的选择，但是我们可以通过计划的重新启动轻松进行常规部署。

听起来像我们正在使用Tomcat部署管理器小工具。我基本上没有任何经验，只是我们知道。就是说，在我工作的地方，我们使用两种设置。

在server.xml文件中，上下文具有属性reloadable =" true"。

我们要做的就是将WAR文件放在正确的位置，然后Tomcat解压缩并重新加载它，没问题。

现在，当我查找它时，官方配置参考中说：

"This feature is very useful during application development, but it requires significant runtime overhead and is not recommended for use on deployed production applications."

就像我说的，我们从来没有遇到过问题。我们的系统处理大量请求，我们似乎没有问题。不过，我们从未将这两种配置相互对照。

我们可能需要尝试一下。至少我们会了解这样做是否足以重新加载内容。我们也可以检查性能，看看是否对我们有问题。

我应该注意，偶尔情况并不正常，无论如何我们都必须重新启动Tomcat，但这是相对罕见的。

如果这行得通，我们所要做的就是让脚本在正确的位置复制WAR，并进行监视以确保一切正常。足够的部署后，Tomcat会耗尽永久性空间，因此我们必须意识到，可能仍然需要手动重新启动Tomcat。

其他随机猜测：

• 我们是通过FTP直接进入最终的WAR位置吗？也许Tomcat只是试图过早打开它？
• 我们收到任何错误消息吗？也许可以找到问题所在？
• 我们是否尝试过其他版本的Tomcat(如果可用)？也许5.5没问题(如果使用5.5，则为5.0)？也许只是更新的发行版？

如果查看bin目录中的tomcat启动和关闭.bat(或者.sh)脚本，我们会发现它们实际上运行Java进程来启动tomcat，或者在关闭的情况下，连接到tomcats的shutdown端口请参见服务器conf目录中的.xml。
我们可以将build ant任务配置为以与脚本相同的方式调用tomcat jar。

我们正在使用哪个版本的tomcat？
究竟是什么使它看起来像"热"部署不起作用？

Tomcat是否注册为Windows服务？

如果是这样，只需使用netstart和netstop编写一个.bat脚本，并将其作为部署过程的最后一步。

reloadable =" true"

不启用战争文件的重新部署(这将自动工作)，而是启用对WEB-INF / classs和WEB-INF / lib中文件更改的监视，这可能不是我们想要的。

在Tomcat中重新部署War文件的大多数情况下，冻结时，我能够将其追溯到classloader泄漏，请参阅Classloader泄漏：可怕的" java.lang.OutOfMemoryError：PermGen空间"异常

我们没有提供太多细节，为什么热部署"无法正常工作"，但是如果它实际上是由于锁定了/ WEB-INF / lib中的资源引起的(这不是很常见的原因；我们会看到这个(通常使用JavaMail API的mail.jar)，然后只需将Context的antiResourceLocking属性设置为true。这是Webapp的/META-INF/context.xml的示例：

<Context antiResourceLocking="true">
    <!-- Your stuff here. -->
</Context>