在应用程序服务器的某处设置数据库连接（如用户名、密码、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 文件更易于管理。在处理与环境没有依赖关系的设置时，我更喜欢这个选项或是特定于应用程序的。