Tomcat 虚拟主机配置混乱

Posted 2023-02-25

【中文标题】Tomcat 虚拟主机配置混乱

【英文标题】：Tomcat Virtual Host configuration confusion

【发布时间】：2014-06-15 22:02:43

【问题描述】：

我正在将我的第一个 Groovy/Grails 应用程序部署到 Tomcat 6 服务器上，但在尝试在 Tomcat 上配置虚拟主机时遇到了一些困惑。我运行 Grails 附带的 Tomcat 部署脚本，它将 WAR 文件复制到 webapps 文件夹下的 Tomcat 服务器并解压缩它（或者我不确定 Tomcat 是否会这样做）。所以我有以下内容：

C:\Program Files\Tomcat\webapps\myapp.WAR
C:\Program Files\Tomcat\webapps\myapp\all files from the WAR

通过使用服务器的 DNS 名称，我可以毫无问题地访问它：

http://server.dns.com/myapp/

但是，我在尝试为此创建虚拟主机时遇到了问题。我在 server.xml 文件中添加了以下几行：

<Host name="www.fancynewdomainname.com" appBase="webapps/myapp"
      unpackWARs="true" autoDeploy="true"
      xmlValidation="false" xmlNamespaceAware="false">
</Host>

但我得到的只是空白页。

我试过用谷歌搜索这个问题，但我越读越困惑。

附：作为旁注，我注意到在将此虚拟主机添加到 server.xml 文件后，我还有以下文件夹：

C:\Progrma Files\Tomcat\work\Catalina\www.fancynewdomainname.com\

但它似乎主要是空的，其中只有几个空文件夹，模仿 WAR 文件中的文件夹。

【问题讨论】：

您找到合适的解决方案了吗？我也面临着类似的问题。

【参考方案1】：

尝试从appBase 属性中删除上下文名称，例如appBase="webapps".

编辑：

如果我正确理解您要实现的目标，我认为您需要为每个虚拟主机定义一个单独的 appBase，例如：

<Host name="www.somedomainname.com" appBase="webapps" ...
<Host name="www.fancynewdomainname.com" appBase="webapps2" ...

然后在每个 appBase 中，将主 webapp 重命名为“ROOT.war”（这样就可以在没有上下文名称的情况下访问它）。

【讨论】：

这是令人困惑的事情之一......如果我将其更改为“webapps”，Tomcat 怎么知道将 dns 名称指向“webapps/myapp”与“webapps/myotherapp”或“ webapps/myotherotherapp”？

感谢您的编辑...不幸的是，这需要手动部署，因为 Grails Tomcat 部署脚本将应用程序放在 webapps 文件夹中，并且它们会扩展到 webapps 文件夹的子文件夹中。但是，我相信我想出了如何做到这一点。我会尽快发布答案。

【参考方案2】：

将原始 server.xml 行更改为以下内容似乎可以使事情正常进行：

<Host name="www.fancynewdomainname.com" appBase="webapps"
      unpackWARs="true" autoDeploy="true"
      xmlValidation="false" xmlNamespaceAware="false">
  <Context path="" docBase="myapp"/>
</Host>

基本上，我将 appBase 更改为“webapps”，并添加了包含上下文定义的行，该定义在 webapps 下实际指向正确的应用程序。

【讨论】：

我说得太早了。这确实有效，因为它正确地到达了主机指向的“应用程序”，但是，它忽略了应用程序中定义的所有上下文信息，因为我在 server.xml 文件中包含了一个上下文条目。所以这不是一个合适的解决方案。

【参考方案3】：

在 Grails Config.groovy 中，您可以通过添加以下内容来更改上下文：

grails.app.context = "$appName-helloworld"

顺便说一句，是 Tomcat 解开了这场战争。将 unpackWARs 设置为 false 将阻止这种情况发生。

另一种处理方法是将 Apache HTTP 服务器放在前面，然后代理到您的 Tomcat 服务器。这也提供了额外的保护层。