我的应用程序部署为EAR文件。
传统上，应用程序需要对某些安装后配置进行更改。
使用Oracle 10G OAS很容易，因为EAR被分解到一个目录中，因此可以轻松访问配置文件。
使用11G时，EAR不会爆炸，导致有关爆炸，修改和重新组合EAR的其他文档。
在我看来，这对于解决方案来说是一个相对常见的问题，也许是通过J2EE的标准解决方案，我根本没有遇到或认为它是我正在寻找的解决方案。
一些替代方案包括： 1）提供将在部署之前修改EAR文件的实用程序。 2）将所有配置设置存储在单独的位置。 3）将所有配置设置存储在数据库中;通过容器提供通过JNDI公开的连接来访问数据库。
但是，是否有既定的最佳实践？
缺乏这种方法，有什么方法对你有用？
由于 柯蒂斯
答案 0 :(得分：3)
我和我的一位客户围绕这个主题做了一些重要的工作。简而言之（我相信应该帮助你）：
如果您要使用配置文件，将配置文件放入EAR（通过爆炸/重新打包）的缺点是让您的EAR文件在不同环境之间不可移植（例如， QA环境与生产环境）。随着时间的推移，这会增加开销，并且环境之间始终存在奇怪的混淆机会。这种方法仅适用于环境无关的配置项 - 即在所有SDLC环境中保持相同（QA，测试等）。
或者，您可以将这些文件放在单独的目录中，并将该目录添加到服务器的类路径中。在每个应用程序服务器中以不同方式执在WebSphere中，这是使用“共享库”工具完成的。
从长远来看，一种对我们更有效的方法是使用实际指定用于此类任务的J2EE技术 - 使用resource environment entries，可通过java:comp/env命名空间下的标准JNDI机制访问
我更喜欢资源环境条目的方法而不是其他任何方法......在尝试了几乎任何可能的解决方案之后。
答案 1 :(得分：0)
据我所知，这仍然是一个痛点，你的分析大多是正确的。
这是我在java.net论坛上很久以前写过的一篇类似问题的更详细的answer，但我们使用的是Glassfish。
关于这个问题，我没有听说过规范有任何根本性的变化，但可能有一些Oracle AS特定的东西有帮助。