是否有一种典型的方法来处理Java应用程序中不同tomcat实例的单独配置？

我们的系统分为不同的环境，每个环境作为一个单独的Tomcat实例

• 开发（Windows）
• QA：由我们的QA部门（Linux）访问
• 生产：现场，可供客户访问。（Linux）

这些环境中的每一个都依赖于单独的数据库和其他几个web服务。这意味着我们需要跟踪各种不同的URL、用户名和密码。这些设置中有许多是在多个应用程序之间共享的，因此最好将它们都放在一个地方以消除重复

现在，我们在应用程序本身中有配置文件。在构建应用程序时，我们使用Maven配置文件填充不同的配置设置。但这是笨拙的，因为我们必须为每个环境构建不同的战争

哪里是存储配置文件的好地方，以便我们可以将相同的WAR文件部署到每个服务器

---

我已经对此做了大量的研究。但我还没有找到一个对我来说完全有意义的解决方案

单独的配置目录 定义保存配置文件的目录。例如linux上的

/opt/config

我喜欢这个想法，但是我如何告诉Tomcat这个目录在哪里呢？我看到了对

context.xml

的引用，但我看到的每个示例都将context.xml放在WAR中的META-INF文件夹中。有没有办法在战争之外进行配置

用于定义环境的系统属性 这涉及到设置一个系统属性，然后使用某种if/else或切换逻辑来加载相应的配置文件。这似乎可行，但有点混乱。但是在哪里/如何设置此属性？我通常使用

/startup.sh

启动tomcat。我是否向该命令添加了参数，或者是否有其他配置

JNDI

---

我不认为这是我们的选择。我看过的每个教程似乎都依赖于LDAP或类似的东西。据我所知，我们没有可用的配置文件，仅为六个配置文件进行设置似乎开销太大。

使用系统属性，该属性指向配置文件或目录所在的位置。在这种情况下，您可以轻松地管理不同的环境，而不需要if/else逻辑

您的应用程序可以具有配置文件路径的硬编码值，这将允许运行应用程序而无需任何额外的系统属性。但是，如果未找到必需的数据，应用程序将无法启动

关于在环境之间部分共享数据。 您可以按类别将数据拆分为多个文件。一些文件将被共享，另一些文件将因不同的环境而不同。您甚至可以开发自己的数据文件间引用机制

---

然而，更好的方法是使用一些现成的软件包。例如，Spring框架支持非常灵活的配置机制。然而，如果您已经有了无Spring应用程序，那么引入此框架进行配置似乎是一种过激的行为。在这种情况下，请看一看

与我的团队合作完成了这项工作，我们认为这是一种更干净的方法。虽然我找到的每个教程都将context.xml放在WAR中，但它也可以放在Tomcat目录的conf文件夹中

---

这对我们很有用，因为我们所有的服务器都是基于Tomcat的。因此，每台服务器都可以有自己的context.xml，它有一个指向该特定服务器上配置文件夹的属性。

这对您来说可能有些过分，但我喜欢。在我的上一份工作中，我们将属性写到Tomcat的config dir中，该应用程序可以看到该属性。也许不是最好的解决方案，但它对我们有效。另一个选项是通过JVM上的-D参数传入属性路径。不过，您确实需要摆弄tomcat配置。