我们的团队构建并拥有一个网络服务框架。其他实际构建 Web 服务的团队使用我们的框架来实现一些常见功能。打包 EAR 有两种选择。选项 1 是将所有框架 jar 都内置到 EAR 中。方案二是在应用服务器中配置一个共享库，让所有应用都使用这个库。我们有可能部署多达 100 个 EARS，它们将使用这个框架。这种方法在构建、可管理性和开发方面有哪些优点和缺点。我们正在使用 websphere。
【问题讨论】：
标签： jakarta-ee websphere
基本的权衡是内存消耗与版本管理。
如果您将库打包到 EAR 中，那么每个应用程序将创建自己的类实例，消耗一定数量的 permgen（或等效项）并占用静态数据的堆空间。
如果您在应用程序的 lib 目录中存储了一个库，那么每个类将只有一个实例。但是，这意味着使用该库的每个应用程序都必须使用相同的版本，并且（除非确保向后兼容）必须同时升级。
鉴于您说的是 100 个 EAR，版本管理问题可能会很大。除非您的库绝对庞大（并且我将假设您在具有大量内存的 64 位服务器上运行，因此请使其变得庞大），或者永远不会改变（不太可能），我建议打包使用 EAR。
【讨论】：
要注意的另一件事是，如果您想在 EAR 之间共享对象实例，例如使用 websphere dynacache，这些对象的类需要从共享库中加载。 （否则，即使它们可能是相同的类/版本，它们也会被不同的类加载器加载，并且不兼容）
我通常也采用简单的“将所有内容打包到 EAR”方法，但随后对需要共享的内容进行例外处理，并将这些类放入一个特殊的共享 JAR 中。
【讨论】：
我也建议使用 EAR 打包。广告 kdgregory 指出管理数百个程序，升级所暗示的测试量变得令人生畏；此外，您应该使用版本控制系统来管理二进制文件的实例以供客户端使用。
【讨论】：
我同意（几乎）之前关于该主题的所有内容：除非您有充分的理由不这样做，否则请继续将所有库打包到 EAR 中，并享受独立、自给自足的 EAR 带来的好处。
不过，请注意，如果您的第三方库使用静态区域进行初始化，那么您可能希望将其打包在 EAR 中。一个明显的例子是 Log4J。 Log4J 每个类加载器只初始化一次。因此，如果您希望每个 EAR 有不同的 Log4J 配置，那么您别无选择，只能将 Log4J JAR 文件与每个 EAR 一起放置。否则，Log4J JAR 将使用所有 EAR 通用的类加载器加载，将加载一次（并初始化其自己的静态区域），并且该配置将对所有使用 Log4J 的应用程序有效。
【讨论】：
您可以使用 WebSphere 的共享库工具，而不是将通用 jar 放入 lib/app。这确实允许将同一共享库的不同版本分配给不同的应用程序，从而为 msnsging 版本提供一定的灵活性。
各种共享方法往往会带来一些复杂性，您需要仔细研究所涉及的类加载器。
我的偏好是保持简单，将所有内容打包在 EAR 中。这是简单、直接的 Java EE。每个应用都可以选择自己的框架版本采用率。
请参阅 Keys Botzum 关于包装的文章common code。
【讨论】：