为什么我应该使用JavaEE服务器库而不是应用库？

我们有一个包含所有lib（jsf、javassit、slf4f vs…）的应用程序。因为我们是在tomcat上开发的，tomcat不提供任何额外的库。我们正在尝试将其移动到JavaEE服务器上，如Weblogic、Jboss、WebSphereVS

我的问题是，为什么我更喜欢服务器库而不是应用程序库？服务器lib是否提供更好的性能？

---

我可以更改类加载顺序，也可以将这些服务器用作servlet容器。

使用服务器库不一定会带来任何性能优势，但是，您必须理解为什么它们比应用程序库更受欢迎

Libs/JAR文件可以隐式引用

如果您有几个不同的应用程序使用Spring框架，那么将SpringJAR文件放在所有实用程序都可以引用的公共位置可能会更容易。这样做可以避免JAR的多个副本出现在整个文件系统中

Java运行时JAR的公共位置，称为“扩展目录”，默认情况下位于lib/ext子目录中，位于已安装的JRE位置下方

JRE是一个可定制的位置，但它很少在给定的Java环境中进行定制，因此可以完全安全地假设lib/ext是存储JAR的安全位置，并且JAR将在Java环境的类路径上隐式可用

---

这最终将使部署更加简单

现在许多常见的应用程序配置方面都是由JavaEE应用程序服务器驱动的，比如维护数据源（db连接）、JMS和EJB设置。JavaEE服务器然后提供查找机制，如JNDI等。。访问这些功能。因此，所有相关JAR都应该是JavaEEServers lib文件夹的一部分

---

现在，与许多应用程序相关的所有通用JAR都可以在j2ee服务器库中维护，但现在在nexus/maven等中央存储库中维护它更合适，如果有其他Web应用程序使用相同的库，则使用服务器加载的库可以节省大量内存。它们只需加载一次。如果没有其他此类Web应用程序，则没有区别。

服务器库具有以下优势：

• 最重要的是：app server core和您的代码之间没有版本冲突。JavaEE服务器必须根据规范为您的应用程序提供一些API类。在war/ear中不要重复这些类，这一点很重要
• 减少战争/耳朵的大小
• 减少服务器的内存消耗

---

当您切换到新版本的应用服务器时，它也使生活变得更轻松。例如，如果您使用maven和wildfly，那么就可以为有关库的信息提供集中的位置。切换到新版本的wildfly时，您可以在maven pom中编辑一行。

在我看来，节省的内存不适用。过去，人们在一台应用服务器（AS）上使用多个应用程序。如果它们都引用了同一个库，则可以节省内存

但现在这太疯狂了。出于安全考虑，每个应用程序都应该有自己的AS（最好是在自己的Docker实例中）

我建议不要使用AS的库：它们的升级路径并不总是与您的（作为开发人员）一致。这可能会给您（dev）带来麻烦。但从老年退休金计划的角度来看，这对他们来说很好，因为这一切都“稳定”

我的建议是：禁用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路线时，只有一个优势：减少战争规模。您最多可以节省30Mb。我想这在1999年是一个优势。

对于Java EE服务器来说，实际上只有一个原因：

因为Java EE是为在服务器上具有此功能而设计的

您可以将其与JDK进行比较，在JDK中，类似于

java.util.HashMap

的内容将成为已安装JDK的一部分。你不应该在你的申请中包括这个

当涉及Servlet、JSP、EL或WebSocket类时，您还可以将其与Tomcat进行比较（它们最终也作为jar存在于Tomcat中）。您也不会将它们包括在war中，因为它们是Tomcat的一部分，而不是应用程序的一部分

在JavaEE中，它的许多组成部分（如JSF、JPA、CDI等）都有很大程度上独立于其他实现的部分，但也有特定于应用服务器的部分。这称为SPI代码或集成代码。这使得CDIBean可以注入servlet，CDI可以向有状态会话bean添加作用域（并在作用域结束时销毁该bean）等等

由于这个集成方面，通常不可能从war内部更新实现JAR（例如JSF），更不用说用不同的实现（例如MyFaces的Mojarra）替换实现JAR了

现在，一些服务器对特定实现的支持有限。例如，由于只有两种JSF实现，供应商可以同时支持这两种实现，并允许您交换它们。不幸的是，如果JavaEE的所有功能都得到支持的话，那么它是否有效以及是否以这种方式支持JavaEE的所有功能都是一个未知数。例如，众所周知，Servlet、JSP和EJB很难交换，尽管在这里做了一些早期的努力

一般来说，在t