在 EAR 文件中保留配置设置的最佳实践是什么？
我的应用程序部署为 EAR 文件。
该应用程序传统上要求进行一些安装后配置更改。
对于 Oracle 10G OAS，这很容易，因为 EAR 被分解到一个目录中，从而可以轻松访问配置文件。
对于 11G，EAR 不会分解，从而产生有关分解、修改和重新组合 EAR 的附加文档。
在我看来，这一定是一个相对常见的问题，有一个解决方案，也许是 J2EE 的标准解决方案，但我根本没有遇到或认识到它是我正在寻找的解决方案。
一些替代方案包括： 1) 提供一个实用程序，可在部署之前修改 EAR 文件。 2) 将所有配置设置存储在单独的位置。 3）将所有配置设置存储在数据库中；通过容器提供通过 JNDI 公开的连接来访问数据库。
但是否有既定的最佳实践呢？
如果缺乏这一点，哪种方法对您有效？
谢谢 柯蒂斯
My application is deployed as an EAR file.
The application has traditionally required that some post installation configuration changes be made.
This was easy with the Oracle 10G OAS as the EAR was exploded into a directory thus allowing easy access to configuration files.
With 11G, the EAR is not exploded resulting in additional documentation on exploding, modifying, and recombining the EAR.
It seems to me that this must be a relatively common problem with a solution, perhaps a standard one through J2EE, that I have simply not come across or recognized it as the solution I was looking for.
Some alternatives include:
1) Providing a utility that will modify the EAR file prior to deployment.
2) Store all configuration settings in a separate location.
3) Store all configuration settings in a database; access the database via a container provide connection exposed through JNDI.
But is there an established best practice?
Lacking that, what approach has worked for you?
Thanks
Curtis
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我和我的一位客户围绕这个主题做了一些重要的工作。简而言之（我相信这应该对您有所帮助）：
如果您要使用配置文件，将配置文件放入 EAR 中（通过分解/重新打包）的缺点是您的 EAR 文件不可用- 可在不同环境之间移植（例如，QA 环境与生产环境）。随着时间的推移，这会增加开销，并且环境之间总是存在混淆的奇怪机会。这种方法仅适用于与环境无关的配置项，即在所有 SDLC 环境（QA、测试等）中保持不变。
或者，您可以将这些文件放在单独的目录中，并将该目录添加到服务器的类路径中。每个应用程序服务器的执行方式都不同；在WebSphere 中，这是使用“共享库”工具完成的。
从长远来看，对我们更有效的方法是使用实际指定用于此类任务的 J2EE 技术 - 使用资源环境条目，可通过 java 下的标准 JNDI 机制进行访问:comp/env 命名空间。
在尝试了几乎所有可能的解决方案之后，我更喜欢资源环境条目的方法而不是其他任何方法。
I have done some significant work around this subject with one of my clients. In a nutshell (which I believe should help you):
If you were to use configuration files, placing configuration files inside the EAR (through exploding / re-packaging) has the drawback of having your EAR files non-portable between different environments (for example, QA environments vs. Production environments). Over time, this increases overhead and there's always the odd chance of confusion between environments. Such approach is only viable for configuration items that are environment agnostic - that is, remain the same across all SDLC environments (QA, test etc).
Alternatively, you could place these files in a separate directory and add that directory to your server's classpath. This is done differently in each application server; in WebSphere, this is done using the "shared libraries" facility.
An approach that worked for us better, over the long run, is to use what J2EE technology actually designated to use for such tasks - using
resource environment entries, accessible via standard JNDI mechanism under thejava:comp/envnamespace.I would prefer the resource-environment entries' approach over anything else... after trying out pretty much any possible solution.
据我所知，这仍然是痛点之一，您的分析大部分是正确的。
这是我很久以前在java上写的一个更详细的答案。 net 论坛上有一个类似的问题，但我们使用的是 Glassfish。
对于这个问题，我还没有听说规范有任何根本性的变化，但可能有一些 Oracle AS 特定的东西可以提供帮助。
As far as I know, this is still one of the pain point, and your analysis is mostly correct.
Here is a more elaborated answer I wrote long time ago on java.net forum to a similar question, but we were using Glassfish.
I haven't heard of any fundamental changes in the spec when it comes to this issue, but there might be some Oracle AS specific thingy that helps.