java - 如何配置/创建自定义类路径，与jetty中许多Web应用程序中的少数几个一样常见

Question

我们有多个Web应用程序打包为war并部署在jetty服务器的jetty.base中。我们正在使用9.4.26.v20200117 jetty 版本。可以说，a.war, b.war, c.war and d.war 。这些分为两类。 Group 1 -> a.war and b.war ，和Group 2 -> c.war and d.war 。我们在jetty.base/lib/ext中有外部依赖jar文件和jetty.base/lib/group2 。只有组 1 Web 应用程序归我们组织中的我的团队所有，组 2 归其他团队所有，

我们有-module-ext已启用，因此外部库位于 jetty.base/lib/ext被加载到服务器类路径和 extraClassPath配置用于第 2 组 Web 应用程序的上下文 xml(c.xml 和 d.xml)中，以从 jetty.base/lib/group2 加载外部库.

这里的问题是当我通过 jetty.base/lib/ext 中的外部 jar 进行升级时到最新版本，这会影响第 2 组 Web 应用程序，因为 jetty.base/lib/ext被加载到系统类路径中，并且对所有 Web 应用程序都是可见的。已决定打破群体之间的这种耦合。我们(第 1 组)无法使用 extraClassPath 配置，因为我们有相同的实例要在第 1 组 Web 应用程序之间共享。我猜的一种可能的方法是，在jetty.base/lib中创建一个目录(比如 jetty.base/lib/group1 )并从 jetty.base/lib/ext 移动外部 jar至jetty.base/lib/group1 ，创建自定义类路径并从 jetty.base/lib/group1 加载外部 jar进入其中并配置此自定义类路径仅适用于第 1 组 Web 应用程序。任何有关如何实现此目标或任何其他可能的解决方案的建议都将受到赞赏。

提前致谢!

Answer 1

“Web 应用程序之间的共同依赖关系”是 JNDI 存在的原因之一。

“减少war包大小”是一个虚假的原因(Jetty已经测试了高达4GB的war文件，WEB-INF/lib中有大约5,000个jar，总计超过2,000,0亿个条目)

方案一:正确使用WAR文件，消除共享依赖。

如果您跳过常见的共享依赖项，您...

• 缩短服务器启动时间。
• 缩短网络应用的部署时间。
• 允许热部署工作(您不会最终锁定/固定类加载器)
• 内存使用量减少(当您使用没有共享资源的传统 war 文件时，使用的文件描述符更少)
• 文件系统 I/O 减少(从多个类加载器访问共享 jar 资源上的文件锁/争用等)

选项 2:正确使用 JNDI。

如果您仍然需要共享资源(请注意，我说的是“资源”，不是依赖项，不是类加载器等)，那么请考虑通过 API 设置资源并与 JNDI 共享该资源。

您可以在服务器级别将资源绑定(bind)到您选择的 JNDI 位置，仅公开 API 作为使用技术。

将 API jar(不是实现 jar)放入每个 Web 应用程序的 war 文件 WEB-INF/lib 中。

拥有 Web 应用程序，通过 JNDI 查找访问公共(public)资源，通过 API 使用该资源。

这将分割资源以及各种类加载器如何正确运行。

服务器类加载器负责公共(public)资源实现。

每个 webapp 类加载器负责自己的 API jar，通过 JNDI 层访问公共(public)资源。

选项 3:放弃整个 WebApp 类加载器隔离并反转行为。

考虑到您对问题的描述，此选项不太可能是一个好的选择，只是为了完整性而将其包含在此处。

在您的 WebAppContext 中，您可以切换类加载器查找行为的完全工作方式。从Servlet具体方式，到Java具体方式。

使用WebAppContext.setParentLoaderPriority(true)使用 Java 行为。

这意味着当您的 Web 应用程序需要一个类时，它会首先检查父类加载器(服务器)，然后再检查 Web 应用程序来加载类。