為什么我應該使用Java EE服務器庫而不是app libs？

Question

我們有一個應用程序，其中包含所有庫（jsf，javassit，slf4f vs ...）。 因為我們在tomcat上開發它而tomcat不提供任何額外的庫。 我們正試圖將它移到Java EE服務器上，如Weblogic，Jboss，Websphere vs ...

我的問題是為什么我更喜歡服務器庫而不是我的應用程序庫？ 服務器庫是否提供更好的性能？ 我可以更改類加載順序，我可以使用這些服務器只是一個servlet容器。

Answer 1

服務器庫具有以下優勢：

• 最重要的是：應用服務器核心與您的代碼之間沒有版本沖突。 Java EE服務器必須按規范為您的應用程序提供一些API類。 重要的是在戰爭/耳朵內沒有這些類的重復
• 減少戰爭/耳朵的大小
• 減少服務器的內存消耗

當您切換到新版本的應用程序服務器時，它也會讓生活變得更輕松。 例如，如果您使用maven和wildfly，那么Wildfly BOM會提供有關庫信息的集中位置。 切換到新版本的wildfly時，您可以在maven pom中編輯一行。

Answer 2

IMO節省的內存不適用。 過去，人們在一個應用服務器（AS）上使用多個應用程序。 如果它們都引用了相同的庫，則可以節省內存。

但現在這太瘋狂了。 出於安全原因，每個應用程序都應該擁有自己的AS（最好是在它自己的Docker實例中）。

我建議不要使用AS的庫：它們的升級路徑並不總是與你的（作為開發人員）一致。 這可能會給你（開發）帶來麻煩。 但是從操作方面看，它對他們來說很好，因為它的“穩定性”。

我的建議：禁用AS庫並包含您自己的庫。 使用JBoss就像這樣簡單：

在WEB-INF文件夾文件jboss-deployment-structure.xml中：

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
  <deployment>
    <exclusions>
       <module name="org.hibernate"/>
          <module name="org.jboss.logmanager.log4j" />
          <module name="org.slf4j" />
          <module name="org.slf4j.impl" />
    </exclusions>
  </deployment>
</jboss-deployment-structure>

我自己的休眠和日志記錄。 事情又應該如此。

AS制造商希望您根據實施情況實施他們的庫和代碼，在您知道之前，您已經與特定AS結合。 不要被愚弄。

使用完整的AS路線時只有一個優勢：戰爭規模減小。 您可以節省高達30Mb。 我想這是1999年的優勢。

Answer 3

使用服務器庫不一定需要提供任何性能優勢，但是，您必須了解它們優先於應用程序庫的原因。

可以隱式引用Libs / JAR文件。

如果您有幾個不同的應用程序可以使用Spring框架，那么將Spring JAR文件放入一個所有實用程序都可以引用的公共位置可能會更容易。 這樣做可以避免在整個文件系統中彈出多個JAR副本。

Java運行時JAR的公共位置（稱為“擴展目錄”）默認位於lib / ext子目錄中，位於已安裝的JRE位置下方。

JRE是一個可定制的位置，但在給定的Java環境中很少自定義，因此可以完全安全地假設lib / ext是存儲JAR的安全位置，並且它們將在Java環境的CLASSPATH中隱式可用。

這最終會使部署變得更加簡單！

Answer 4

現在，許多常見的應用程序配置方面都是由Java EE應用程序服務器驅動的，例如維護數據源（數據庫連接），JMS和EJB設置。 然后，Java EE服務器提供查找機制，如JNDI等，以訪問這些函數。 所以所有相關的jar都應該是Java EE服務器lib文件夾的一部分。

現在所有與許多應用程序相關的常見jar都可以在j2ee服務器lib中維護，但是現在將它保存在中央存儲庫中就像nexus / maven更合適的選擇

Answer 5

如果有其他Web應用程序使用相同的庫，則使用服務器加載的庫可以節省大量內存 。 它們只需要加載一次。 如果沒有其他此類Web應用程序則沒有區別。

Answer 6

對於Java EE服務器，實際上只有一個原因：

因為Java EE旨在在服務器上具有此功能

您可以將它與JDK進行比較，其中java.util.HashMap東西應該是已安裝的JDK的一部分。 您不應該將此包含在您的應用程序中。

當涉及到Servlet，JSP，EL或WebSocket類（最終在Tomcat中也作為jar存在）時，您也可以將它與Tomcat進行比較。 您也不包括戰爭中的那些，因為它們是Tomcat的一部分，而不是您的應用程序的一部分。

在Java EE中，它的許多組成部分（如JSF，JPA，CDI等）具有很大程度上獨立於其他實現的部分，但也包含特定於應用程序服務器的部分。 這稱為SPI代碼或集成代碼。 這使得CDI bean可以在Servlet中注入，CDI可以將范圍添加到有狀態會話bean（並在范圍結束時隨后銷毀bean）等等。

由於這種集成方面，通常不可能在戰爭中更新實現jar（例如JSF），更不用說用不同的實現交換實現jar（例如Mojarra for MyFaces）。

現在一些服務器對特定實現的支持有限。 例如，由於只有兩個JSF實現，供應商可以支持它們並允許您交換它們。 不幸的是，這是一個錯過，並且是否有效，並且到目前為止並非所有Java EE功能都支持這種方式，如果它完全受支持的話。 盡管Servlet，JSP和EJB很難交換，盡管這里有一些早期的努力。

通常，在服務器級別將這些實現jar與應用程序存檔分開的優點是啟動和重新部署時間，以及應用程序和框架代碼之間的明確分離。 具體而言，每次重新啟動/重新部署應用程序時，都不必掃描像JSF這樣的Java EE實現jar。

在任何時候，Tomcat都是一種中間解決方案。 您將在服務器級別（Servlet，JSP，EL，如上所述的WebSockets）和戰爭中的某些類（JSF，JPA等）中擁有一些類/ jar。 這也是恕我直言，也不完全是最優的。

最近流行的另一個選擇是將整個應用程序服務器+應用程序部署為單個可運行的jar（“fat jars”）。 這里詳細介紹了這個答案的范圍，但是查找例如WildFly Swarm或Payara embedded / micro 。

ps在其他答案中已經提到了幾次，但我還要強調，將幾個不相關的應用程序部署到單個應用程序服務器然后期望獲得內存優勢通常不是一個好主意。 安全性和資源利用率以及恕我直言的升級問題遠遠超過任何潛在的內存節省。

Answer 7

我用於Application Server庫的最大原因是企業一致性。

在一家公司中，你有多個團隊都在構建應用程序，如果所有團隊只是將jar文件拼湊到他們的war文件中，那么他們就會有效地推出他們自己的應用程序服務器。 這會消耗大量的開發人員資源，因為他們試圖找出一起工作正常的不同罐子的確切版本。 這也意味着我會讓DevOps支持一堆不同版本的JPA，JMS隊列，集群，緩存等......

如果我讓我的團隊在應用服務器上實現標准化，我知道生產中會有更少的驚喜。 我可以從應用服務器供應商那里購買支持，並且知道當緩存不工作時，有一種明確的方法可以解決它。