在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機制進行訪問。

我更喜歡資源環境條目的方法比其他任何...在嘗試了幾乎任何可能的解決方案之後。