5

我们的团队构建并拥有一个 Web 服务框架。其他实际构建 Web 服务的团队使用我们的框架来实现一些常见功能。打包 EAR 有两种选择。选项 1 是将所有框架 jar 都内置到 EAR 中。方案二是在应用服务器中配置一个共享库，让所有应用都使用这个库。我们有可能部署多达 100 个 EARS，它们将使用这个框架。这种方法在构建、可管理性和开发方面有哪些优点和缺点。我们正在使用 websphere。

4

5 回答 5

8

基本的权衡是内存消耗与版本管理。

如果您将库打包到 EAR 中，那么每个应用程序将创建自己的类实例，消耗一定数量的 permgen（或等效项）并占用静态数据的堆空间。

如果您在应用程序 lib 目录中存储一个库，那么每个类将只有一个实例。但是，这意味着使用该库的每个应用程序都必须使用相同的版本，并且（除非确保向后兼容）必须同时升级。

鉴于您谈论的是 100 个 EAR，版本管理问题可能会很大。除非您的库绝对庞大（并且我将假设您在具有大量内存的 64 位服务器上运行，因此请使其变得庞大），或者永远不会改变（不太可能），否则我建议打包与 EAR。

于 2009-07-04T12:15:09.193 回答
2

另一件要注意的是，如果您想在 EAR 之间共享对象实例，例如使用 websphere dynacache，则需要从共享库中加载这些对象的类。（否则，即使它们可能是相同的类/版本，它们也会被不同的类加载器加载并且不兼容）

我通常也采用普通的“将所有内容打包在 EAR”方法中，然后对需要共享的内容进行例外处理，并将这些类放入一个特殊的共享 JAR 中。

于 2009-07-06T17:26:16.913 回答
0

我也建议用 EAR 打包。广告 kdgregory 指出管理数百个程序，升级所暗示的测试量变得令人生畏；此外，您应该使用版本控制系统来管理二进制文件的实例以供客户端使用。

于 2009-07-04T13:37:49.667 回答
0

您可以使用 WebSphere 的共享库工具，而不是将通用 jar 放入 lib/app。这确实允许将同一共享库的不同版本分配给不同的应用程序，从而为 msnsging 版本提供一些灵活性。

各种共享方法往往会导致一些复杂性，您需要仔细研究所涉及的类加载器。

我的偏好是保持简单，将所有内容打包在 EAR 中。这是简单、直接的 Java EE。每个应用程序都可以选择自己的框架版本采用率。

请参阅 Keys Botzum 关于打包公共代码的文章。

于 2009-07-05T19:56:21.163 回答
0

我同意（几乎）之前关于该主题的所有内容：除非您有充分的理由不这样做，否则请继续将所有库打包到 EAR 中，并享受独立、自给自足的 EAR 带来的好处。

但是，请注意，如果您的第三方库使用静态区域进行初始化，那么您可能希望将其打包在 EAR 中。一个明显的例子是 Log4J。Log4J 每个类加载器只初始化一次。因此，如果您希望每个 EAR 有不同的 Log4J 配置，那么您别无选择，只能将 Log4J JAR 文件与每个 EAR 一起放置。否则，Log4J JAR 将使用所有 EAR 通用的类加载器加载，将加载一次（并初始化其自己的静态区域），并且该配置将对所有使用 Log4J 的应用程序有效。

于 2012-10-05T08:31:56.997 回答