2010-09-21 81 views
2

我的應用程序被部署爲EAR文件。在EAR文件中保存配置設置的最佳實踐是什麼?

該應用程序傳統上需要進行一些安裝後配置更改。

這是很容易與Oracle 10G OAS作爲EAR被分解成從而允許方便地訪問配置文件的目錄。

隨着11G,該EAR不分解導致在爆炸,修改和重新組合EAR附加文檔。

在我看來,這一定是一個可以解決的比較普遍的問題,也許是一個標準J2EE通過,我已經根本就沒有碰到過或認可它,因爲我一直在尋找解決方案。

一些替代方案包括: 1)提供了一個實用工具,將改變之前部署EAR文件。 2)將所有配置設置存儲在一個單獨的位置。 3)將所有配置設置存儲在數據庫中;通過JNDI公開的容器提供連接訪問數據庫。

但是,有沒有一個確定的最佳實踐?

缺乏這一點,有什麼方法爲你工作?

感謝 柯蒂斯

回答

0

據我所知,這仍然是痛點之一,你的分析是正確的大部分。

這是一個更加完備answer我前寫很長一段時間java.net上論壇,類似的問題,但我們使用的是GlassFish。

我還沒有聽說過在規範的任何根本變化,當談到這個問題,但可能有一些甲骨文AS具體啄幫助。

+0

感謝您確認我的恐懼。 :) – 2010-09-24 21:10:15

+0

(對不起,沒有足夠的聲望點給你的答案點頭) – 2010-09-24 21:10:42

3

我已經做了一些重要的工作,圍繞這個問題與我的客戶之一。概括地說(我相信應該可以幫助你):

如果你使用的配置文件,把配置文件耳內(通過爆炸/重新包裝)具有您的EAR文件的缺點非可以在不同環境之間移植(例如,QA環境與生產環境)。隨着時間的推移,這會增加開銷,並且環境之間始終存在奇怪的混淆機會。這種方法只適用於環境不可知的配置項 - 也就是說,在所有SDLC環境(質量保證,測試等)中保持不變。

或者,您可以將這些文件放在單獨的目錄中,並將該目錄添加到服務器的類路徑中。這在每個應用程序服務器中都是不同的。在WebSphere中,這是使用「共享庫」功能完成的。

,對於我們更好地工作,從長遠來看的一種方法,是使用什麼J2EE技術​​實際上指定使用此類任務 - 使用resource environment entries,通過java:comp/env命名空間下的標準JNDI機制進行訪問。

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

+0

艾薩克,謝謝你的迴應。我會研究使用環境條目。 (對不起,沒有足夠的代表給它豎起大拇指,我希望別人會代表我) – 2010-10-12 14:12:41

相關問題