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