在Java EE應用程序中設置類加載順序以偏好應用程序類的缺點

在我的WebSphere 8應用程序服務器上，默認類加載順序爲parent_first（嘗試從應用程序服務器類加載器加載，然後從EAR類加載器）。
這會在我的應用程序使用Apache的HttpClient和WebSphere的內部使用情況之間產生衝突。
我正在考慮將加載訂單切換爲parent_last（prefer-web-inf-classes in WebLogic）。在Java EE應用程序中設置類加載順序以偏好應用程序類的缺點

將Java EE應用程序類加載順序翻到parent_last時需要注意哪些問題？

來源

2013-01-16 Gili Nachum

應該沒有。

PARENT_LAST允許您的應用程序使用與WebSphere相沖突的類和jar進行分發。當兩個不同的不兼容類加載器加載WebSphere AS和您的應用程序中的類時，只要發生ClassClassException，就會使用該設置。

類加載程序模式 - PARENT_FIRST和PARENT_LAST - 在Class loaders in the WebSphere Application Server 8.0 Information Center中描述。

人們傾向於將應用程序中的jar包捆綁在一起，使得部署時間更長，內存消耗更高，並且（庫）管理更困難。

開發人員在應用程序中保留所有內容顯然更容易，因此他們無需描述管理員必須設置的共享庫（或OSGi存儲庫）的設置。

我想不出PARENT_LAST有幫助的情況，除非我們假設在一個應用程序中分發jar是一件好事（我會爭論點）。

越少罐子是在應用程序中，更好：

應用程序可以從升級其罐中獲益時，一個問題的通過共享庫或OSGi的版本庫，將緩解其維護
應用程序可以共享庫固定這會降低內存預期並提高可重用性（顯然部署速度更快）

有可能有更多的理由不在應用程序中捆綁JAR，這會進一步降低PARENT_LAST配置設置。

棒與PARENT_FIRST，直到他們告訴你，他們已經有了一個理由，開關，當它發生了，你告訴他們答案;-)

來源

2013-01-17 10:49:40

謝謝Jacek，儘管我不同意。如果您的堆以GB爲單位進行度量，則IMO加載類所需的堆空間並不重要。最近的歷史讓我們認爲你可以更好地打包你所需要的東西，否則你會得到API破壞（DDL HELL），或者你從來沒有測試過的不受歡迎的infra組件升級的不良行爲。 –

這就是爲什麼有OSGi與其確切的導入包/導出包版本控制方案。我堅信OSGi的價值，儘管它可能不像許多人想要的那樣對開發人員友好。着名的jar地獄是當你失去了你的依賴版本的控制。當你從環境中聲明你需要的是一對（名稱，版本）時，你不應該面對不兼容的問題（除非對（名稱，版本）不是「穩定的」，這意味着你依賴於非常不穩固的地面）。 –

哦，好的。明白了。所以OSGI消除了導入/ x.y.z的任何版本/ /的含糊性。對於那些願意支付開發費用的人看來確實很強大。謝謝！ –

從Understanding the IBM Software Developers Kit (SDK) for Java > Class loading：

[代表團型號]通過假設與核心 API的一部分具有相同的名稱，防止信任不良來源的代碼替換可信核心API類。

因此，PARENT_LAST似乎存在的情況下，由於版本不兼容，應用程序必須重寫基類，但這樣做意味着它也可能削弱安全性。

來源

2013-01-17 13:41:38 ewernli

有趣，但我無法想象這種安全形式如何將我的EAR與我信任的Jars打包在一起。 –

@GiliNachum當然，它只有從託管環境的角度來看，應用程序的運營商。服務器不需要信任應用程序上部署的應用程序的開發人員。服務器。你相信你的罐子;但運營商可能不相信*你*。 – ewernli

在Java EE應用程序中設置類加載順序以偏好應用程序類的缺點

回答

相關問題