戰爭包與共享庫內的依賴關係

Question

通常，依賴關係捆綁在Java .war-packages內。

然而，也可能會下降的依賴關係到共享庫中，使用相同的依賴關係爲每個部署的工件的。

問題：什麼是每一種方法的優點和缺點？在哪些情況下你會使用它們？

最大的要求是直觀性/可維護性。我不關心內存消耗，磁盤空間使用率，帶寬等，因爲這些購買很便宜。

無論如何，一些點，每個：

裏面包括WAR依賴關係：（？）

• 「時點」 的方法
• 易於維護（需要更少的配置&腳本等）
• 易於部署到應用服務器
• 每個模塊都可以在圖書館
定義特定版本210
• 減少類加載錯誤的風險？

使用共享庫：

• 減少內存消耗（瑣碎？）
• WAR部署可以訪問相同的實例/變量等，因爲它們共享類路徑？這聽起來真的很糟糕？ （它真的工作方式，或者是他們在不同的上下文中運行，只是使用相同的物理文件？）
• 了做分佈和部署更加困難，因爲依賴關係必須被單獨維護/部署
• 包是在較小大小（平凡）
• 依賴最多可以升級，沒有戰爭的應用程序的實際重新部署（有什麼好處，真的..）

當然，我們可以使用兩種方法的最好的方面，只是提供通用庫作爲共享庫，並在WAR中包含版本特色。但是，這使維護工作倍增，感覺像是一個不行。

目前我使用Glassfish的3.1.1，但這個問題確實是應用服務器不可知。

Answer 1

這取決於您的操作。如果您將應用程序部署在服務器上並且此類服務器的數量非常有限（例如，集成，QA，生產），並且您有很多依賴關係，那麼可將將依賴關係存儲到共享庫中。

如果你要戰發送到已部署了服務器上的這場戰爭是非常惱人的第三方用戶。窮人用戶必須在他的共享庫中安裝所有必需的依賴關係（以及依賴關係的依賴關係）。

如果您必須將應用程序安裝在不是您自己的服務器上或需要運行多個企業應用程序的服務器上，您就不能使用此方法。你必須將你所有的依賴打包到你的war文件中。否則，衝突是不可避免的。

Answer 2

鑑於您上面的pro/con列表，它在我看來就像您已經回答了您的問題。正如你所說，內存/磁盤很容易來。另一方面，時間並不容易。將依賴關係放在WEB-INF/lib中被證明是很容易的，並且可以讓應用程序避免與其他人或系統類加載器進行奇怪的交互。如果它沒有被破壞...

Answer 3

好處就像你說的 - 每個應用程序都是獨立的，即不需要立即在所有已部署的應用程序中升級庫。加上只有類路徑衝突，你應該期望的是，當相同的庫在容器和應用程序 - 我不記得它很好，類加載可以在不同的容器中有所不同。

如果您的意思是「WAR部署」各種應用程序，不要期望共享任何東西 - 這些都是通過設計隔離的。共享依賴可以在磁盤上單獨升級，但是何時以及如何發生取決於容器的類加載器。

因此，建議是：保持標準方法，只檢查您爲不必要的依賴關係構建的WARs/JARs。