在EAR文件中保存配置设置的最佳实践是什么？

Question

我的应用程序被部署为EAR文件。

该应用程序传统上需要进行一些安装后配置更改。

这是很容易与Oracle 10G OAS作为EAR被分解成从而允许方便地访问配置文件的目录。

随着11G，该EAR不分解导致在爆炸，修改和重新组合EAR附加文档。

在我看来，这一定是一个可以解决的比较普遍的问题，也许是一个标准J2EE通过，我已经根本就没有碰到过或认可它，因为我一直在寻找解决方案。

一些替代方案包括： 1）提供了一个实用工具，将改变之前部署EAR文件。 2）将所有配置设置存储在一个单独的位置。 3）将所有配置设置存储在数据库中;通过JNDI公开的容器提供连接访问数据库。

但是，有没有一个确定的最佳实践？

缺乏这一点，有什么方法为你工作？

感谢 柯蒂斯

Answer 1

据我所知，这仍然是痛点之一，你的分析是正确的大部分。

这是一个更加完备answer我前写很长一段时间java.net上论坛，类似的问题，但我们使用的是GlassFish。

我还没有听说过在规范的任何根本变化，当谈到这个问题，但可能有一些甲骨文AS具体啄帮助。

Answer 2

我已经做了一些重要的工作，围绕这个问题与我的客户之一。概括地说（我相信应该可以帮助你）：

如果你使用的配置文件，把配置文件耳内（通过爆炸/重新包装）具有您的EAR文件的缺点非可以在不同环境之间移植（例如，QA环境与生产环境）。随着时间的推移，这会增加开销，并且环境之间始终存在奇怪的混淆机会。这种方法只适用于环境不可知的配置项 - 也就是说，在所有SDLC环境（质量保证，测试等）中保持不变。

或者，您可以将这些文件放在单独的目录中，并将该目录添加到服务器的类路径中。这在每个应用程序服务器中都是不同的。在WebSphere中，这是使用“共享库”功能完成的。

，对于我们更好地工作，从长远来看的一种方法，是使用什么J2EE技术​​实际上指定使用此类任务 - 使用resource environment entries，通过java:comp/env命名空间下的标准JNDI机制进行访问。

我更喜欢资源环境条目的方法比其他任何...在尝试了几乎任何可能的解决方案之后。