OSGi之Bundle

2024-04-20 05:24:27

OSGi提出的根源是什么？在我看来就是对JVM的类加载机制进行了扩展，添加了一系列的规则，使得原有的类包（Class Package）扩展到类域(Class Domain)。然后是建立在类域上的一系列松耦合应用。

在OSGi R4中，核心部分分为了4层：安全层（Security Layer）、模块层（Module Layer）、生命周期层（Life Cycle Layer）和服务层（Service Layer）。其中模块层是整个OSGi概念的核心部分。OSGi的核心实现即为OSGi框架，它本身也是一个OSGi Bundle。

OSGi中的重要元素就是Bundle 和Service，Bundle提供了一种静态资源边界，类似于Web容器中的Web应用的概念。

每一个Bundle通过一个元数据文件（MANIFEST.MF）描述。OSGi框架（即SystemBundle）通过解析这个元数据文件对该 Bundle进行加载和管理。Bundle通过元数据中的"Export-Package"属性将内部的类包发布给OSGi系统中其他Bundle使用，通过"Import-Package"，"Requie-Bundle"属性引用OSGi系统中其他Bundle发布的类包。

每一个 Bundle有自己独立的类加载器（Fragment Bundle例外，其资源通过其Host Bundle加载），Bundle内部的资源（类，文件等）通过该类加载器查找和加载。Bundle的类加载器能够控制的类加载边界包括：启动类路径上的类资源，OSGi框架即SystemBundle上的类资源和Bundle内部的类资源。该类资源边界即形成该Bundle的类域。

每一个Bundle在OSGi框架中具有自己的生命周期，其生命周期内的状态包括：INSTALLED、RESOLVED、STARTING、ACTIVE、STOPPING和UNINSTALLED。

INSTALLED状态是Bundle的初始状态，当该Bundle部署到OSGi系统的Bundle Repository中时，Bundle的状态标记为INSTALLED。

Bundle内部的资源在加载之前，首先由OSGi框架对其进行解析（Resolve），解析的过程就是分析Bundle的元数据的过程，详细过程参考OSGi规范。解析后的Bundle进入RESOLVED状态，解析失败时，仍然处于INSTALLED状态。

Bundle内的资源被其它Bundle使用时，该Bundle被启动，也可以通过设定让OSGi框架在加载该Bundle时直接启动。

Bundle 内的资源通过BundleContext与其他Bundle进行交互。元数据中的"Bundle-Activator"属性指定了实现 BundleActivator接口的实现类，Bundle通过该类得到BundleContext，通过BundleContext可以查找其他的 Bundle，查找注册在OSGi中的服务（Service）与OSGi环境进行交互等等。Bundle可以在其提供的BundleActivator实现类中进行初始化的工作，也可以注册服务到OSGi的服务注册表中，供其他Bundle查找使用。

最新文章

热门文章