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