因此，今天下午我花了一些时间终于坐下来，开始阅读神秘而难以捉摸的“OSGi”及其所谓的捆绑包。
好吧，我想我明白了。OSGi“捆绑包”基本上是一个包含一些附加清单信息的JAR。而且，您不必将其部署到普通的应用程序服务器（或其他容器），而是将其部署到像Apache Felix这样的OSGi服务器上。它运行，然后向用户/客户端提供服务。
这与部署到应用程序服务器的普通 EAR 有何不同???
OSGi似乎正在崛起（我一直在遇到它！），但就我而言，我不明白它提供了什么（功能方面），而不是你可以用GlassFish或Spring等真实交易企业服务器做任何事情。
我知道这个世界并没有疯掉，所以我显然错过了一些东西。只是无法弄清楚是什么。感谢您的任何帮助或见解！
OSGi捆绑包更像是一个“软件模块”，而不是一个“jar”，“war”或“ear”文件。如果OSGi捆绑包捆绑了整个应用程序，则很少提供好处;但是，它们在连接大量库的自动化和正确处理方面非常有益。
因此，考虑OSGi试图解决的问题，您将更好地了解它适合的位置。它是Java相当于C++的“钻石继承”模式。您包括两个库，每个库都需要一个公共日志记录库，但在本例中，这不是因为多重继承，而是因为多个 include 语句。
如果这两个库都使用相同版本的公共日志记录库，那么您很幸运。如果不这样做，那么要使每个库独立正常工作，您需要加载同一库的两个副本，每个副本可能使用相同的命名空间（并且通常使用相同的类名）。
OSGi是一种捆绑方式，它允许加载同一库的两个版本，它们使用相同的命名空间，相同的类名，但在不同的时间创建。它还将“正确”版本连接到“正确”OSGi捆绑包，防止捆绑软件使用“正确”库的“错误”版本。
Java EE做了很多事情，但这甚至不是Java EE解决的问题。充其量，Jigsaw项目也在研究同样的问题。Java EE / OSGi混淆发挥作用的地方在于，OSGi捆绑的大多数早期采用者都是那些实现类似于Java EE中提供的一些库的功能的人。也就是说，实际的容器连接框架（OSGi）与捆绑功能无关（尽管一些发现在结构上进行了修改，以符合OSGi捆绑要求）。
将Java EE与OSGi进行比较就像比较苹果和橙子以及不知道什么是什么的额外好处。
Java EE 的重点是异构环境中的可扩展多层业务应用程序和企业范围的信息系统集成。
OSGi从另一个角落开始，将几个独立的代码库集成到一个JVM中（请原谅我非常简短）。
当然，有些问题（例如热部署）在两种环境中都是通用的 - 但程度不同。
当然，你可以升级，降级和杂交他们俩，他们会在中间的某个地方相遇。
因此，问题不应该是“A比B有什么好处”，而是“在哪个领域A比B有明显的优势，反之亦然？让我改写一下：“我什么时候需要锤子，什么时候需要锯子？
