跨多个Tomcat实例维护JNDI

Ish*_*Ish 8 deployment tomcat jndi production-environment

我想知道人们如何管理跨Tomcat应用程序服务器的多个实例维护JNDI资源.让我们以我的数据库JNDI资源为例.它在我的/conf/context.xml文件中声明,并从我的apps web.xml文件中引用.

必须在我的开发框,登台框和生产框中独立定义JNDI资源.如果我想设置开发人员/登台/生产箱的新实例怎么办?这意味着我必须在context.xml中为我提出的每个新实例重新创建资源名称?从设置角度来看,这是一个可能导致应用服务器开始指向错误数据库的人为错误的地方.

我发现这是繁琐和令人困惑的,因为我扩大了我的项目的开发人员数量以及最终我可能使用的生产服务器的数量.

你只是将它作为你的设置的一部分,或者每次重新安装tomcat并设置一个盒子时创建一个处理这个的安装脚本吗?或者是否有一些其他级别的间接可以使这更容易?

Chs*_*y76 1

您是否正在部署多个必须使用共享资源的 Web 应用程序?

如果没有,绝对没有理由在 /conf/context.xml 中声明您的资源。它们应该在 Web 应用程序的单独、私有的 context.xml 文件中声明,该文件将在 WAR 中部署为 /META-INF/context.xml。该文件以及您的 web.xml 应检入您的源代码控制系统并作为构建的一部分进行部署 - 无需任何手动干预。

如果您要部署具有共享资源的多个 Web 应用程序,您可以编写一个自定义资源工厂,将相同的资源公开给多个 Web 应用程序(请参阅页面底部的Tomcat 文档)并使用上述方法,或者 - 对于开发环境,请访问至少 - 您可以自动更改(甚至替换为默认值不执行任何操作) /conf/context.xml 作为构建的一部分。当然,对于生产部署,这是不可取的。

  • 我没有投反对票,但我强烈不同意你的观点。诸如 JDBC 数据源和邮件会话之类的资源绝不应该在 WAR 本身中定义。数据库连接参数是环境的属性,而不是应用程序的属性。在投入生产之前,人们应该能够在测试环境中部署 WAR。 (5认同)
  • 将 _same_ WAR 文件部署到 QA 和 PROD 可以确保在测试和上线之间不会发生任何变化。您不想要的是希望您没有忘记为生产构建签入正确版本的配置文件。这也意味着每次从 prod 回到 dev(补丁)、测试到 prod、回到 dev(增强)、测试到 prod 等转换时,不必拥有 200 个版本的配置文件。 (3认同)