【问题标题】:Best practices for a "multi plugins" Java web application - Managing common libraries and conflictual versions“多插件”Java Web 应用程序的最佳实践 - 管理通用库和冲突版本
【发布时间】:2014-04-03 12:54:48
【问题描述】:

我是一个 web 项目的新手,我们必须开发插件(在该特定项目中称为“extensions”)。主应用程序在修改后的 Tomcat Web 服务器中运行,我们必须将插件的 .jars 添加到公共 lib 文件夹中。我仍然不太习惯该应用程序及其工作方式,但我很确定该应用程序及其所有插件都有一个通用的类加载器。该 lib 文件夹中的所有库都是共享的。

我的问题是如何在那种环境中处理插件的依赖关系和潜在的冲突版本。

我们是否应该在 lib 文件夹中有共享库,例如 some-common-lib-1.3.4 作为 jars 并且插件必须在需要时使用 那些版本使用图书馆?

或者插件是否应该包含它自己的依赖项(例如使用Maven Shade Plugin),所以相同依赖项的不同版本不是问题?

我看到让 共享库 具有用于所有插件的特定版本的问题是关于传递依赖关系。如果一个公共库依赖于some-transitive-dependency-1.0.0,而我们有一个特定的插件需要一个新的库,而该库本身对some-transitive-dependency-2.0.0 具有传递依赖,那么我们就完蛋了……然后我们需要some-transitive-dependency-1.0.0 和@ lib 文件夹中的 987654326@,谁知道会发生什么。

此外,如果对于某个特定插件,我们需要将依赖项更新到新的主要版本,我们可能必须更新 所有 个插件,因为该库是由所有人共享的。

在这种情况下有任何现实世界的经验吗?有什么建议吗?

【问题讨论】:

  • 看起来你应该研究在 Tomcat 上部署 OSGI 容器(如 Karaf)并让它处理依赖关系的破坏......
  • @Cascader 在不使用 OSGI 或 Jigsaw 的情况下,人们一般如何处理这种情况?这就是我好奇的地方!因为我很确定我们不能改变这个应用程序的工作方式和加载它的库:它们都必须放在 lib 文件夹中。

标签: java maven tomcat web-applications jar


【解决方案1】:

由于 OSGI 不是一个选项,而且可能每个人都可以创建新插件,因此分离它们的唯一可行方法是,正如您已经建议的那样,使用 shade 插件或一些类似的技术。

由于您无法分离类加载器并重新编译所有插件(您甚至可能没有源代码)实际上不是一种选择,有时您甚至可能遇到无法解决的冲突(asm 1.x 和 2.x 完全不兼容),您必须使用自己的“穷人的 OSGI”并使用阴影。

但是请注意,这确实会减少插件协同工作或共享未在主应用程序中定义的公共数据的选项。

【讨论】:

    猜你喜欢
    • 2011-02-18
    • 2017-05-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-03-11
    • 1970-01-01
    相关资源
    最近更新 更多