什么是Java EE 7属性文件配置的最佳实践建议？

应用程序配置在哪里属于现代Java EE应用程序？ 人们有什么最佳实践建议？

通过应用程序配置，我的意思是设置连接设置到其他盒子上的服务，包括外部服务（例如Twitter和我们的内部Cassandra服务器……用于诸如主机名，凭证，重试尝试之类的东西）以及与业务逻辑相关的东西（事物）一个人可能会被诱惑作为常量存储在类中，例如某些东西过期等等。

假设：

1. 我们使用单个EAR文件部署到Java EE 7服务器（Wildfly 8.1），该文件包含多个战争和一个ejb-jar。
2. 我们将部署到各种环境：unit testing，本地开发安装，基于云的UAT基础架构，压力测试和生产环境。 我们的许多房产会因这些环境而异。
3. 如果这是人们推荐的最佳实践，我们不反对将属性配置耦合到DI框架。
4. 所有这些都是为了新的开发，因此我们不必遵守传统的要求或限制。 我们非常关注当前的现代最佳实践。

配置是属于EAR的内部还是外部？

如果在 EAR 之外 ，哪里以及如何最好地可靠地访问它们？

如果在 EAR 内部 ，我们可以将它存储在类路径中的任何位置，以便在执行期间轻松访问。 但是我们必须在每次配置更改时重新组装（并且可能重新构建）。 由于我们将拥有多个环境，因此我们需要一种方法来区分EAR中的文件。 我在这里看到两个选项：

1. 利用预期的文件名（例如cassandra.properties ），然后构建多个特定于环境的EAR（例如， appxyz-PROD.ear ）。
2. 构建一个EAR（例如appxyz.ear ）并将所有各种环境配置文件放入其中，将环境变量附加到每个配置文件名（例如cassandra-PROD.properties ）。 当然还要添加一个环境变量（到vm或其他），以便代码知道要拾取哪个文件。

人们可以推荐哪些最佳实践来解决这一共同挑战？

谢谢。

Answer 1

我不知道什么是最佳实践，但这就是我们的工作。

（但请注意，这仅适用于每个服务器的每个应用程序的一次安装，并且当每个服务器想要使用多个部署时，例如多租户部署时，将会失败）。

CDI注入属性值

我们使用一种稍微复杂的CDI注入方法将.properties文件中的配置值直接注入到bean中，如下所示：

 @Inject @ConfigurationValue(value="amazonS3FileContentsAccessKey") private String accessKey; 

相应的@Producer bean从类路径和给定的“本地”位置读取配置文件：

全局/本地.properties文件

1. 每个EAR在类路径上包含一个“全局” .properties文件，用于配置值很少变化和/或通常在环境中保持一致（例如某些事物过期的天数）。 此外，全局配置文件包含合理的默认值（例如，数据库服务器主机名的“ localhost ”）。 全局properties文件（有多个，见下文）在源树中维护。
2. 对于每个开发环境/安装/服务器/部署，（可能）是一个“本地”属性文件，其中包含覆盖全局配置设置的本地设置，例如数据库名称，密码等。

“本地”属性文件的预期路径在全局配置文件（例如/etc/myapp/local.properties ）或C:\myapp\local.properties 。

实际上，我们甚至允许在文件名中替换本地配置文件中的一些变量，例如“ ${hostname} ”。 最初的想法是，通过主机名（ local.machineA.properties ， local.machineB.properties ）区分它们，也可以在一些中央源控件中维护本地属性，但我们目前不使用它，因为我们的生产所有计算机上的设置都相同（Amazon S3密钥，数据库密码/主机等）。

组装开发，测试，生产

我们根据使用Maven配置文件的开发阶段组装不同的EAR。
一开始，将所需的global.${profile.name}.properties文件（其中profile.name ，例如dev或production ）复制到类路径中的预期global.properties文件中。

例如， dev和testing共享一个共同的AmazonS3秘密/存储桶，它在configuration.dev.properties文件中为所有开发人员配置一次，而configuration.production.properties则不包含我们的生产密钥。

此外，我们的dev和testing环境已经启用并配置了调试，比如web.xml ，但当然staging和production都没有。 我们基于.properties的方法无法更改web.xml等文件，但使用Maven构建配置文件很容易。

Answer 2

根据每个人的经验，您的问题可以有许多可能的解决方案。 所以，为什么不试试一些已经讨论过的想法。 请看看

1. 为dev / QA / prod配置Java EE 6
2. 如何配置Java EE应用程序以应用不同的设置

希望这两个能让您对如何使用maven构建整个环境有一些共识。