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

Question

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

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

假设:

1. 我们使用单个EAR文件部署到Java EE 7服务器(Wildfly 8.1),该文件包含多个战争和一个ejb-jar.
2. 我们将部署到各种环境:单元测试,本地开发安装,基于云的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;

相应的@Producerbean从类路径和给定的"本地"位置读取配置文件:

全局/本地.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.
在assemply上,所需的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. 为开发/QA/产品配置 Java EE 6
2. 如何配置 Java EE 应用程序以应用不同的设置

希望这两篇文章能让你对如何使用maven构建整个环境有一些共同的理解。