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