所以今天下午我终于坐下来，开始阅读神秘而难以捉摸的"OSGi"和它所谓的包。
好，所以我认为我明白了。OSGi"包"基本上是一个带有一些附加清单信息的JAR。而且，不是将其部署到普通的应用程序服务器(或其他容器)，而是将其部署到像Apache Felix这样的OSGi服务器。它运行，然后为用户/客户端提供服务。
这与部署到应用服务器上的普通EAR有什么不同?
OSGi似乎正在崛起(我一直在遇到它!)，但是对于我来说，我不明白它提供了什么(功能方面)比你可以用真正的企业服务器(如GlassFish或Spring)做的任何事情。
我知道这个世界还没有疯狂，所以我显然错过了什么。只是还不知道是什么。感谢任何帮助或见解!
OSGi包更像是一个"软件模块"，而不是一个"jar"、"war"或"ear"文件。如果捆绑了整个应用程序，OSGi包很少提供好处;然而，它们在连接大量库的自动化和正确处理方面是非常有益的。
考虑一下OSGi试图解决的问题，您将更好地理解它的适用范围。它相当于c++中的"菱形继承"模式。您包含两个库，每个库都需要一个公共日志库，但在这种情况下，这不是因为多重继承，而是因为多个include语句。
如果这两个库都使用相同版本的通用日志库，那么您很幸运。如果没有，那么为了使每个库独立地正确工作，您需要加载同一个库的两个副本，每个副本可能使用相同的名称空间(并且通常使用相同的类名)。
OSGi是一种绑定的方式，它允许加载同一个库的两个版本，它们使用相同的名称空间，相同的类名，但在不同的时间创建。它还将"正确"的版本绑定到"正确"的OSGi包，防止一个包使用"正确"库的"错误"版本。
Java EE做了很多，但这不是Java EE甚至解决的问题。充其量，拼图项目也是在解决同样的问题。Java EE/OSGi混淆的地方在于，大多数OSGi捆绑的早期采用者都是那些实现类似于Java EE中提供的某些库的功能的人。也就是说，实际的容器连接框架(OSGi)与捆绑功能没有任何关系(尽管一些发现在结构上进行了修改，以符合OSGi捆绑需求)。
比较Java EE和OSGi就像比较苹果和橙子，除了不知道什么是什么。
Java EE的重点是异构环境中可伸缩的多层业务应用程序和企业范围内的信息系统集成。
OSGi从另一个角落开始，将几个独立的代码库集成到一个JVM中(请原谅我非常简短)。
当然一些问题(例如热部署)在这两个环境中都是常见的——但是程度不同。
当然你可以升级，降级和杂交，他们会在中间的某个地方相遇。
所以问题不应该是"A比B有什么好处"，而应该是"在什么领域A比B有明显的优势，反之亦然?"让我换个说法:"我什么时候需要锤子，什么时候需要锯子?"
很抱歉，这里所有的答案都很可笑。OSGi解决了依赖版本问题?Pooooohlease……听说过应用服务器中的类加载器策略吗?
OSGi似乎是一个不断销售新书和培训的想法，而功能需求已经被JAR/EAR包装覆盖了很久了。JEE部署。那些相信它的人根本不知道他们是如何被操纵的。还有一个趋势和时尚的问题。也就是说，非工程方面的考虑是这个行业的耻辱。
重新发明轮子是有利可图的，因为外面有很多傻瓜。不幸的是，有大量的管理型傻瓜想要站在"技术前沿"，他们很乐意为员工的课程提供资金，吸收学习曲线，然后花大价钱"重新设计"那些一开始就没有问题的东西。这不是"我是用螺丝刀还是锤子"的问题。这更像是一个"嘿，老板，有个新东西叫HEMMAR，它真的很酷!"的问题。"这不是锤子吗?"，"不，不，它好得多，它是HEMMAR，它是用来把钉子钉进木板的，它将彻底改变世界。"
大多数主要优点，至少是我们使用OSGi的原因，都在http://karaf.apache.org/中列出，尤其是前两个。
此外，OSGi联盟还有一长串好处:https://www.osgi.org/developer/benefits-of-using-osgi/.