Java OSGi与jboss热部署

据我所知，在OSGi中，您可以在运行时更新JAR，而无需重新启动服务器。但是jboss也有热部署，其中更新了完整的ear，服务器仍在运行

---

那么，在jboss的企业java项目中，OSGi有什么好处呢？

我相信答案与每个OSGi用例都是一样的：模块化和更精细的更新粒度

OSGi不仅仅是在运行时更新JAR而不重新启动服务器。从您的问题来看，它是在运行时更新JAR，而无需重新启动应用程序

我承认我不知道JBoss AS中EAR热部署的具体实现，但无论如何，EAR更新不可能设计为保留应用程序的整个状态。服务器仍在运行，但基本上在更新时重新启动应用程序。这种状态丢失的程度实际上取决于你如何设计你的应用程序，但事实上你是在独立自主地做事

对于OSGi，情况并非如此：应用程序由一大组bundle组成，每个bundle都有希望处理功能的一个单独部分。这种方法使得应用程序内部热部署，因为框架被设计为考虑重新启动任何单个JAR给应用程序带来的影响，并让其他JAR反应适当。这提供了尽可能多地保留应用程序状态的能力

因此，在企业案例中，OSGi设计的好处是应用程序的活跃性。没有必要强调这一点的重要性。确实，在某些用例中，应用程序可以安全地重新启动。但在我看来，OSGi是当今JavaEE唯一真正可伸缩和可维护的选择。最重要的应用服务器已经（或即将）移动到OSGi运行时（并因此提供OSGi应用程序支持）就是证明

l10i写道：对于OSGi，情况并非如此：应用程序由一大组bundle组成，希望每个bundle都能处理功能的一个单独部分。这种方法使得应用程序内部热部署，因为框架被设计为考虑重新启动任何单个JAR给应用程序带来的影响，并让其他JAR反应适当。这提供了尽可能多地保留应用程序状态的能力

再详细说明一下，最好的OSGi应用程序是通过OSGi服务注册中心集成的面向服务的应用程序。这个服务注册是动态的，服务可以随时来来去去去，OSGi服务消费者对这种动态性做出适当的反应。 假设您的应用程序由许多捆绑包组成，包括使用支付服务的捆绑包（例如，用于处理信用卡支付）和提供该支付服务的另一捆绑包。如果您发现自己的支付服务需要更新（因为您有一个关键的修复程序，或者您可能已经找到了一个更便宜的提供商，等等），您可以更新此支付服务，而无需关闭此服务的消费者。为了实现这一点，您可以更新支付服务包本身，但在这种情况下，我建议您首先在旧版本的基础上安装新版本的支付服务包。这是可能的，因为OSGi允许同一捆绑包的多个版本共存。然后，一旦新的捆绑包启动并运行，您就可以删除旧的支付服务捆绑包，此时消费者将自动切换到使用新的捆绑包，这是OSGi服务注册中心提供的

上述示例中的这种体系结构非常强大，可以确保企业应用程序正常运行，并且可以通过使用OSGi服务以及动态安装、卸载或更新OSGi捆绑包来实现

顺便说一句，上面的例子还有一些细节，因为捆绑包也可以编写为使用特定类型的所有服务-什么对您最合适取决于您的情况

---

有很多方法可以使用OSGi服务注册表，您可以将其与一起使用，这是相当低级的。在大多数情况下，最好为此使用一个框架，如OSGi声明性服务（DS）、OSGi蓝图或其他框架。在大多数情况下，这些框架通过注入工作，并为您处理OSGi服务注册表的动态性。有关DS或Blueprint的信息，请参阅。

我从未听说有人在JEE应用程序服务器上成功地在生产中进行热重新部署（是的，他们都声称您可以做到，但行为不好的LIB总是阻止旧类加载器被垃圾收集）。