Question

我们有一个应用程序，其中包含所有库（jsf，javassit，slf4f vs ...）。因为我们在tomcat上开发它而tomcat不提供任何额外的库。我们正试图在Java EE服务器上移动它，如Weblogic，Jboss，Websphere vs ...

我的问题是为什么我更喜欢服务器库而不是我的应用程序库？服务器库是否提供更好的性能？我可以更改类加载顺序，我可以将这些服务器只用作servlet容器。

Answer 1

服务器库具有以下优势：

最重要的是：应用服务器核心与您的代码之间没有版本冲突。 Java EE服务器必须按规范为您的应用程序提供一些API类。重要的是在war / ear
减少战争/耳朵的大小
减少服务器的内存消耗

当您切换到新版本的应用程序服务器时，它也会让生活变得更轻松。例如。如果你使用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>

我自己的冬眠＆amp;日志记录。事情又应该如此。

AS制造商希望您针对其实施实施他们的库和代码，并且在您知道之前，您已经与该特定AS结合。不要被愚弄。

使用完整的AS路线时只有一个优势：战争规模减小。您可以节省高达30Mb。我想这在1999年是一个优势。

Answer 3

使用服务器库不一定能提供任何性能优势，但是，您必须了解它们优先于应用程序库的原因。

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

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

Java运行时JAR的常用位置，称为＆＃34;扩展目录，＆＃34;默认位于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服务器库中维护，但现在将其保存在中央存储库中，如 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。

P.S。在其他答案中已经提到了几次，但我还要强调，将几个不相关的应用程序部署到单个应用程序服务器然后期望获得内存优势通常不是一个好主意。安全性和资源利用率以及恕我直言的升级问题远远超过任何潜在的内存节省。

Answer 7

我用于Application Server库的最大原因是企业一致性。

在一家公司中，您有多个团队都在构建应用程序，如果所有团队只是将jar文件拼凑到他们的war文件中，那么他们就会有效地推出自己的应用程序服务器。这会消耗大量的开发人员资源，因为他们试图找出一起工作正常的不同罐子的确切版本。这也意味着我会让DevOps支持一堆不同版本的JPA，JMS队列，集群，缓存等......

如果我让我的团队在应用服务器上实现标准化，我知道生产中会有更少的意外。我可以从应用服务器供应商那里购买支持，并知道当缓存不能正常工作时，有一种明确的方法可以解决它。

为什么我应该使用Java EE服务器库而不是app libs？

7 个答案: