使用共享库与完全封装的EAR的优点和缺点

Question

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

Answer 1

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

如果在EAR中打包库，那么每个应用程序将创建自己的类实例，消耗一些permgen（或等效的）以及为静态数据占用堆空间。

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

我的偏好是保持普通香草，将所有东西包装在EAR中。这是简单，直接的Java EE。每个应用程序都可以选择自己的框架版本采用率。

请参阅Keys Botzum关于打包common code的文章。

Answer 5

我同意（几乎）以前写过的关于这个主题的所有内容：除非你有充分的理由不这样做，否则请继续将所有图书馆打包到EAR中，享受独立，自给自足的EAR的好处。 / p>

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