使用共享库与完全封装的 EAR 的优缺点
我们的团队构建并拥有一个网络服务框架。 其他实际构建 Web 服务的团队使用我们的框架来实现一些常见功能。 打包 EAR 有两种选择。 选项 1 是将所有框架 jar 内置到 EAR 中。 选项2是在应用程序服务器中配置共享库并使所有应用程序都使用该库。 我们有可能部署多达 100 个 EARS，它们将使用此框架。 这种方法在构建、可管理性和开发方面有哪些优点和缺点？ 我们正在使用 websphere。
Our team builds and owns a webservices framework. Other teams which actually build the webservices use our framework for some common functionality. There are two options to package the EAR. Option 1 is to have all the framework jars built into the EAR. Option 2 is to configure a shared library in the application server and make all applications use the library. We have potential of upto 100 EARS being deployed, that will use this framework. What are some pros and cons off this approach in terms of build,manageability and development. We are using websphere.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
基本的权衡是内存消耗与版本管理。
如果将库打包在 EAR 中，则每个应用程序将创建自己的类实例，消耗一定量的 permgen（或等效项）并占用静态数据的堆空间。
如果将库存储在应用程序的 lib 目录中，则每个类只会有一个实例。 但是，这意味着使用该库的每个应用程序都必须使用相同的版本，并且（除非确保向后兼容性）必须同时升级。
鉴于您正在谈论 100 个 EAR，版本管理问题可能会很大。 除非你的库绝对巨大（并且我假设你在具有大量内存的 64 位服务器上运行，所以让它变得巨大），或者永远不会改变（不太可能），否则我建议打包与 EAR。
The basic tradeoff is memory consumption versus version management.
If you package libraries in an EAR, then each application will create its own class instances, consuming some amount of permgen (or equivalent) as well as taking up heap space for static data.
If you store a library in the application lib directory, then there will only be one instance of each class. However, it means that each of the applications using that library must use the same version, and (unless backwards compatibility is ensured) must upgrade at the same time.
Given that you're talking about 100 EARs, the version management issue is probably going to be big. Unless your library as absolutely huge (and I'm going to assume that you're running on a 64 bit server with lots of memory, so make that HUGE), or is never going to change (unlikely), I'd suggest packaging with the EAR.
另一件需要注意的事情是，如果您想在 EAR 之间共享对象实例（例如使用 websphere dynacache），则需要从共享库加载这些对象的类。 （否则，即使它们可能是相同的类/版本，它们也将由不同的类加载器加载并且不兼容）
我通常也会采用普通的“将所有内容都打包在 EAR 中”方法，但随后会对那些符合以下条件的内容进行例外处理：需要共享，并将这些类放入一个特殊的共享 JAR 中。
Another thing to note is that if you want to share object instances between EARs, e.g. using the websphere dynacache, the classes for those objects will need to be loaded from shared libraries. (otherwise, even though they may be the same class/version, they will be loaded by different classloaders and not compatible)
I usually go with the plain-vanilla "package everything in EAR" approach as well, but then make exceptions for stuff that needs to be shared, and put those classes into a special shared JAR.
我建议也使用 EAR 进行打包。 Ad kdgregory 指出，管理数百个程序，升级所带来的测试量变得令人畏惧； 此外，您应该使用版本控制系统来管理二进制文件的实例以供客户端使用。
I would suggest packaging with the EAR as well. Ad kdgregory pointed out managing hundreds of programs and the amount of testing implied by upgrades becomes daunting; futhermore you should use a version control system to manage instances of your binaries for the clients to consume.
我（几乎）同意之前关于该主题所写的所有内容：除非您有充分的理由不这样做，否则请继续将所有库打包到 EAR 中，并享受独立、自给自足的 EAR 的好处。
但是，请注意，如果您的第三方库使用静态区域进行初始化，那么您可能最终希望将其打包在 EAR 中。 Log4J 就是一个明显的例子。 Log4J 每个类加载器仅初始化一次。 因此，如果您希望每个 EAR 有不同的 Log4J 配置，那么您别无选择，只能将 Log4J JAR 文件与每个 EAR 放在一起。 否则，Log4J JAR 将使用所有 EAR 通用的类加载器进行加载，将加载自身（并初始化其自己的静态区域）一次，并且该配置将对使用 Log4J 的所有应用程序生效。
I agree with (almost) everything that was written about this subject before: unless you have a very good reason not to, go ahead and package all libraries in the EAR and enjoy the benefit of standalone, self-sufficient EARs.
However, note that if your third-party library uses static areas for initialization, then you might want to package it in the EAR after all. A clear example is Log4J. Log4J initializes itself only once per classloader. Therefore, if you'd like to have a different Log4J configuration per EAR, then you have no choice but to put the Log4J JAR file with each and every EAR. Otherwise, the Log4J JAR will be loaded with a classloader that is common to all of your EARs, will load itself (and initialize its own static areas) once, and that configuration will be in effect for all applications using Log4J.
您可以使用 WebSphere 的共享库工具，而不是将公共 jar 放入 lib/app 中。 这确实允许将同一共享库的不同版本分配给不同的应用程序，从而为 msnsging 版本提供一定的灵活性。
各种共享方法往往会导致一些复杂性，您需要仔细研究所涉及的类加载器。
我的偏好是保持简单，将所有内容打包在 EAR 中。 这是简单、直接的 Java EE。 每个应用程序都可以选择自己的框架版本采用率。
请参阅 Keys Botzum 的有关打包通用代码的文章。
Rather than putting the common jars into lib/app you can instead use WebSphere's shared library facility. This does permit different versions of the same shared library to be assigned to different applications, hence enabling some flexibility for msnsging versions.
The various sharing approaches tend to lead some complexities, you need to study carefully the classloaders involved.
My preference would be to stay plain-vanilla, package everything in the EAR. This is simple, straight Java EE. Each app can choose its own rate of framework version adoption.
Refer to Keys Botzum's article on packaging common code.