OSGi和Java EE之间的根本区别是什么?

IAm*_*aja 18 java osgi java-ee

所以今天下午花了一些时间才最终坐下来开始阅读神秘而难以捉摸的"OSGi"及其所谓的捆绑包.

好的,所以我我明白了.OSGi"bundle"基本上是一个带有一些额外清单信息的JAR.而且,不是将其部署到普通的应用程序服务器(或其他容器),而是将其部署到像Apache Felix这样的OSGi服务器上.它运行然后为用户/客户端提供服务.

这与正常的EAR部署到应用服务器有什么不同?

OSGi似乎正在崛起(我一直在努力!),但对于我的生活,我不明白它提供的功能(功能方面),你可以用像GlassFish或Spring这样的真实交易企业服务器做什么.

我知道世界并没有疯狂,所以我显然错过了一些东西.只是还没弄清楚是什么.感谢您的帮助或见解!

Edw*_*uck 22

OSGi包更像是"软件模块"而不是"jar","war"或"ear"文件.如果捆绑整个应用程序,OSGi捆绑包很少提供好处; 但是,它们对于连接大量库的自动化和正确处理非常有益.

因此,考虑OSGi试图解决的问题,您将更好地了解它适合的位置.它是Java与C++中"钻石继承"模式的等价物.您包含两个库,每个库都需要一个公共日志库,但在这种情况下,它不是因为多重继承,而是因为有多个include语句.

如果这两个库都使用相同版本的通用日志库,那么你很幸运.如果他们不这样做,那么为了让每个库独立工作,你需要加载同一个库的两个副本,每个副本可能使用相同的名称空格(通常是相同的类名).

OSGi是一种捆绑方式,它允许加载同一个库的两个版本,它们使用相同的名称空间,相同的类名,但是在不同的时间创建.它还将"正确"版本连接到"正确"的OSGi包,防止捆绑包使用"正确"库的"错误"版本.

Java EE做了很多,但这不是Java EE甚至解决的问题.充其量,Jigsaw项目正在解决同样的问题.Java EE/OSGi混淆发生的地方是OSGi捆绑的大多数早期采用者是那些实现类似于Java EE中提供的某些库的功能的人.也就是说,实际的容器连接框架(OSGi)与捆绑功能无关(尽管一些发现在结构上进行了修改,以符合OSGi捆绑要求).

  • 像Maven或Apache Ivy这样的可传递依赖项管理器是否不能自行解决此“ JAR地狱”问题?如果我的应用程序依赖于两个库L1和L2,并且L1依赖于joda-time-1.1.jar,而L2依赖于joda-time-1.2.jar,则Ivy将为我解决此问题,只要我同时拥有两个版本在运行时在我的类路径中实现joda-time,我很高兴。仍然没有穿过这里的树木看到森林... (2认同)
  • Ivy可以下载两个jar文件,但是在编译时,Java不允许在同一个名称相同的类加载器中定义两个不同的类。如果将两者都放在类路径上,则第一个满足类名称的名称将返回该类,而不管它是正确的版本还是错误的版本。因此,您需要类加载器树,具体取决于调用类的“捆绑”。这意味着您实际上需要一种跟踪捆绑软件需求的方法,从而跟踪清单文件,并最终跟踪“框架”(又名Jigsaw或OSGi)。 (2认同)