据我所知，在OSGi中，您可以在运行时更新jar而无需重新启动服务器。但是jboss也有热部署，在这种情况下，整个ear被更新，服务器仍在运行。
那么在jboss的企业java项目中使用OSGi有什么好处呢?
我相信每个OSGi用例的答案都是一样的:模块化和更精细的更新粒度。
OSGi远不止在运行时更新jar而不重新启动服务器。从你的问题的角度来看，它是在运行时更新jar而不重新启动应用程序。
我承认我不知道JBoss AS中EAR热部署的具体实现，但是在任何情况下，EAR更新都不可能被设计成保留应用程序的整个状态。服务器仍在运行，但实际上需要在更新后重新启动应用程序。这种状态丢失的程度实际上取决于您如何设计应用程序，但事实仍然是您正在单例地执行操作。
对于OSGi，情况并非如此:应用程序是由一大组bundle组成的，每个bundle都被设计用来处理功能的一个单独部分。这种方法支持应用程序内部热部署，因为框架的设计考虑了重新启动任何单个jar对整个应用程序的影响，并让其他jar做出适当的反应。这提供了尽可能多地保留应用程序状态的能力。
因此，在企业环境中使用OSGi设计的好处是应用程序的活动性。没有必要强调这一点的重要性。确实，有些用例可以安全地重新启动应用程序。但在我看来，OSGi是目前Java EE唯一真正可扩展和可维护的选择。最重要的应用服务器已经(或将要)迁移到OSGi运行时(并因此提供OSGi应用程序支持)的事实就是证明。
l10i写道:使用OSGi就不是这样了:应用程序是由一大组bundle组成的，每个bundle都被设计成处理功能的一个单独部分。这种方法支持应用程序内部热部署，因为框架的设计考虑了重新启动任何单个jar对整个应用程序的影响，并让其他jar做出适当的反应。这提供了尽可能多地保留应用程序状态的能力。
再详细说明一下，最好的OSGi应用程序是通过OSGi服务注册中心集成的面向服务的应用程序。这个服务注册中心是动态的，服务可以在任何时候来来去去，OSGi服务消费者对这种动态做出适当的反应。假设你的应用程序由许多bundle组成，包括一个使用支付服务的bundle(例如用于处理信用卡支付)和另一个提供支付服务的bundle。如果你发现自己处于支付服务需要更新的情况下(因为你有一个关键的修复，或者你找到了一个更便宜的供应商，等等)，你可以更新这个支付服务，甚至不需要让这个服务的消费者下线。要实现这一点，您可以更新支付服务包本身，但在这种情况下，我建议首先在旧版本旁边安装新版本的支付服务包。这是可能的，因为OSGi允许同一bundle的多个版本共存。然后，一旦新包启动并运行，您就可以删除旧的支付服务包，此时消费者将自动切换到使用新的支付服务包，这是OSGi服务注册表提供的。
像上面的例子这样的架构是非常强大的，可以确保你的企业应用程序保持正常运行，它可以通过使用OSGi服务和动态安装、卸载或更新OSGi包的能力来实现。
顺便说一句，上面的例子还有一点细节，因为bundle也可以被编写成使用特定类型的所有服务——根据你的情况，什么最适合你。
有许多方法可以使用OSGi服务注册表，您可以将其与ServiceTracker API一起使用，这是相当低级的。在大多数情况下，最好使用框架，如OSGi声明性服务(OSGi Declarative Services, DS)、OSGi Blueprint或其他框架。在大多数情况下，这些框架通过注入工作，并为您处理OSGi Service Registry的动态性。有关DS或Blueprint的信息，请参见OSGi 4.2 Enterprise Specification。