java - 何时将配置放在 file.properties 或 Jndi 中

Question

长期以来，在许多 IT 服务中，我看到一些复杂的过程来根据环境管理 Java EE 应用程序配置: - 自定义工具，有或没有数据库，用于管理属性文件中的替换(解压缩 war 、替换、压缩 war ……) - 在服务器的模糊目录中外部化属性文件(以及一些时间更新它的过程)和一些时间使用 JNDI 配置... - Maven 配置文件和许多大属性文件

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

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

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

Answer 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

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

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

选项 2(应用服务器中的数据库设置)

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

然后您可以像这样检索DataSource:

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

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

---

结论

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

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