Java WAR打包应用程序的配置文件

当您使用脚本语言开发webapp时，您的项目目录树中有一个文件，其中配置在部署时定义，并在运行时读取以进行初始化。当您将webapp部署为编译的WAR文件时，情况会发生显著变化，因为您既不能访问任何目录树，也不能编辑归档文件的内容

这是我的场景：我的应用程序需要

smtp.properties

在运行时发送电子邮件，因此该文件包含一些我不想与其他Web应用程序共享的敏感信息。这意味着我不会将文件放在

$CLASSPATH

中。另一种选择是在已知位置进行检查，但这存在明显的可移植性问题。举个例子：Linux上有

/etc

，Windows上没有

/etc

目前我使用读取设置，但这会对数据格式施加约束，实际文件的位置取决于servlet容器

所以我的最终答案是：在JavaEE的土地上，与

config.php

（或

config.yml

）最匹配的是什么

---

免责声明：我读了很多类似的问题，似乎简短的回答是不行的。当您希望在部署时覆盖其他组件的设置（如日志记录）时，这也很麻烦。

在Java中，config.php文件的等效文件实际上是web-INF中的web.xml文件。我不认为

有问题，实际文件的位置取决于servlet容器，您从未指定读取其中参数的路径，不是吗

顺便说一下，如果您想在战争中创建自己的属性文件，您可以使用以下方式访问它：

URL propPath = getClass().getResource("your_relative_path");

在JavaEE世界中，要走的路是按照JNDI。在web应用程序中，您可以通过标准化的JNDIAPI读取配置设置。这包括SMTP的登录凭据，但也包括配置的数据库连接等

有关详细信息，请阅读我对一个类似问题的回答：
config.php

的美妙之处在于它可以在部署时手动编辑，而

WEB-INF/WEB.xml

在不爆发（然后重新打包）战争的情况下是无法访问的。而且，它必须是XML。有了Tomcat，如果你想在战争中编辑，就可以使用Yes，因为你必须重新打包战争（并且可能刷新web.xml，我不知道如何…），这将很难以应用服务器和平台无关的方式完成。最通用的方法可能是通过系统属性定义特定于环境的配置文件的位置。对于部署者来说，这是一个额外的步骤，但它的平台不可知，并且可以在应用程序重新部署和应用程序服务器升级中生存下来。这也是我最喜欢的方法，但不是直接的

config.php

这是一个聪明的答案，在问我的问题之前，我已经看过了你之前的帖子。我关心的问题是安全性（因为我从来没有玩过JNDI）：这样每个webapp都将共享相同的配置（例如DB和mail）。另外，我并不完全理解在已经有servlet init参数的情况下使用另一个API的好处。你能概述一下吗？