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

在很多IT服务中,我看到一些复杂的过程来管理Java EE应用程序配置,具体取决于环境: - 自定义工具,数据库与否,以管理属性文件中的替换(解压缩,替换,压缩战争. ..) - 外部化服务器中的obscure目录中的属性文件(以及一些时间更新它的过程)和一段时间使用JNDI配置... - maven配置文件和许多大属性文件

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

为什么对于依赖于环境的所有配置而言,这不是一般化的？

更新:我想要处理除数据源之外的其他变量,对数据源没有任何疑问:它是在JNDI中为Java EE应用程序配置的.如果你想要破解JNDI ...

在应用程序服务器中的某处设置数据库连接(如用户名,密码,URL,驱动程序等)与在WAR中自己完成相比有几个优点:

应用服务器可以是配置数据库的中心点,您可能在该服务器上运行多个共享数据库的WAR.所以你只需要设置一次.

数据库设置,尤其是凭据(用户名,密码)存储在应用服务器中的某个位置,而不是存储在WAR中的某个位置.这可能会产生安全隐患(例如,限制对该文件的访问比在WAR存档中更容易).

您可以设置一个 JNDI路径来检索DataSource指向数据库的实例,而不再需要担心用户名和密码.如果您有多个具有不同数据库URL和凭据的应用服务器(一个实时系统,一个测试系统,多个开发人员机器),那么您可以单独在每个应用服务器中配置它并部署WAR文件而无需更改数据库设置(见下文).

服务器可能会提供其他服务,例如连接池,容器管理事务等.因此,您不必在WAR中自行执行此操作.

对于app服务器提供的其他服务也是如此,例如JavaMail.

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

我想进一步说明第三个要点......
假设你在三个应用服务器(开发者机器,测试服务器,实时服务器)中有一个WAR.

选项1(WAR中的DB设置)

创建一个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(App Server中的数据库设置)

想象一下,您已使用各自的数据库设置配置了三台服务器,并且每台服务器都使用JNDI路径注册数据库java:database/mydb.

然后你可以检索DataSource如下:

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

这适用于每个应用服务器实例,您可以部署WAR而无需修改任何内容.

结论

通过将配置移动到应用服务器,您可以根据应用代码中的环境分离设置.每当你有涉及IP地址,凭证等的设置时,我都会更喜欢这个.

.properties另一方面,使用静态文件更易于管理.在处理不依赖于环境或特定于应用程序的设置时,我更喜欢此选项.