何时将配置放入 file.properties 或 Jndi

Posted 2023-02-26

【中文标题】何时将配置放入 file.properties 或 Jndi

【英文标题】：When to put configuration in file.properties or Jndi

【发布时间】：2016-03-07 20:33:46

【问题描述】：

长期以来，在许多 IT 服务中，我看到一些复杂的过程来管理 Java EE 应用程序配置，具体取决于环境： - 自定义工具，无论是否使用数据库，以管理属性文件中的替换（解压缩战争、替换、压缩战争......） - 在服务器的晦涩目录中外部化属性文件（以及一些更新它的过程）和一些时间与 JNDI 配置...... - maven 配置文件和大量的大属性文件

但是对于数据库连接，每个人都使用 jndi 数据源。

为什么这不适用于依赖于环境的所有配置？

更新：我想处理数据源以外的其他变量，没有关于数据源的问题：它在 JNDI 中为 Java EE 应用程序配置。如果你想破解 JNDI...

【问题讨论】：

看看这个link

它处理tomcat上的数据源，而tomcat不是真正的Java EE服务器。但是它们在将配置放入 Web 应用程序或服务器时处理相同的逻辑。

有什么问题？在哪里放东西？为什么这不是一概而论的？

通常每个人都可以使用 JNDI 数据源，但对于其他配置（wsdl 端点或其他），我不知道 JNDI 与属性的良好做法。 JNDI 数据源对每个应用程序服务器都有很好的记录，但是使用 JNDI 将键/值作为属性文件是另一种用法。

【参考方案1】：

在应用程序服务器的某处设置数据库连接（如用户名、密码、URL、驱动程序等）比在 WAR 中自己做有几个优点：

应用服务器可以是配置数据库的中心点，您可能在该服务器上运行多个 WAR，共享一个数据库。因此，您只需设置一次。 数据库设置，尤其是凭据（用户名、密码）存储在应用服务器中的某个位置，而不是 WAR 中的某个位置。这可能会产生安全隐患（例如，限制对该文件的访问比在 WAR 存档中更容易完成）。 您可以设置一个 JNDI 路径来检索指向数据库的DataSource 实例，而无需再担心用户名和密码。如果您有多个具有不同数据库 URL 和凭据的应用服务器（一个实时系统、一个测试系统、多台开发人员机器），那么您只需在每个应用服务器中单独配置它并部署 WAR 文件，而无需更改数据库设置（见下文）。 服务器可能会提供额外的服务，如连接池、容器管理的事务等。同样，您不必在 WAR 中自行完成。

对于应用服务器提供的其他服务也是如此，例如 JavaMail。

在其他情况下，您希望配置特定于某个 Web 应用程序且不依赖于环境（应用服务器）的内容，例如日志记录（尽管也可以在应用服务器中设置） .在这些情况下，您可能更喜欢使用静态配置文件，例如 log4j.properties。

---

我想进一步说明第三个要点... 假设您在三个应用服务器（开发者机器、测试服务器、实时服务器）中有一个 WAR。

选项 1（WAR 中的数据库设置）

创建一个database.properties：

db.url=jdbc:mysql://localhost:3306/localdb
db.user=myusername
db.pass=mysecretpassword

#db.url=jdbc:mysql://10.1.2.3:3306/testdb
#db.user=myusername
#db.pass=mysecretpassword

#db.url=jdbc:mysql://10.2.3.4:3306/livedb
#db.user=myusername
#db.pass=mysecretpassword

在将其部署到某个地方之前，您需要检查您的设置是否指向正确的数据库！

此外，如果您将此文件签入某个版本控制系统，那么您可能不想将您的数据库用户名/密码发布到您的本地计算机。

选项 2（应用服务器中的数据库设置）

假设您已经使用各自的 DB 设置配置了三个服务器，并且每个服务器都使用 JNDI 路径 java:database/mydb 注册 DB。

然后你可以像这样检索DataSource：

Context context = new InitialContext();
DataSource dataSource = (DataSource) context.lookup("java:database/mydb");

这适用于每个应用服务器实例，您无需修改​​任何内容即可部署 WAR。

---

结论

通过将配置移至应用服务器，您将具有根据环境将设置与应用代码分开的优势。每当您有涉及 IP 地址、凭据等的设置时，我都希望这样做。

另一方面，使用静态.properties 文件更易于管理。在处理与环境没有依赖关系的设置时，我更喜欢这个选项或是特定于应用程序的。

【讨论】：

OK JNDI 通常用于 DataSource，没有问题，但用于其他配置变量。最佳做法是什么？

没有通用的答案，这取决于您的目标。我想说，如果你只为你的 WAR 配置一些东西，并且在部署到不同的服务器时它不会改变，那么坚持使用 .properties 文件，它们会更简单。某些技术/框架需要以一种或另一种方式进行配置，因此这取决于...此外，如果您的 JavaEE 服务器支持配置，您应该使用它而不是 .properties 文件。无需在这里重新发明***。

@Mr_Thorynque 我已经扩展了我的答案。

是的，我明白，JNDI 就是这样。

为什么不创建一个可执行的 jar 而不是部署到应用服务器？这简化了部署，还让您有机会启动它，同时为其提供您想要使用的任何属性文件的路径。还有一些配置服务器可以很好地做到这一点，比如 Spring Cloud Contract。感觉很老派，仍然在构建战争并部署到 tomcat。