OSGi 框架的组件运行机制


OSGi 组件框架

在 OSGi 框架中,组件被称为 Bundle,它是由一些提供 Bundle 自身功能的资源 ( 如 Java 类文件、配置文件等 )、MANIFEST.MF 文件和其它资源文件构成。在运行时环境中,每个 Bundle 都有一个独立的 Class Loader,Bundle 之间通过不同的类加载器和在 MANIFEST.MF 文件中定义的包约束条件就可以轻松实现包级别的资源隐藏和共享,从而实现基于组件方式的开发和运行。 Class Loader 是实现这种运行方式的关键机制,每个 Bundle 的 Class Loader 必须在此 Bundle 得到正确的解析 ( Resolving ) 之后,再由 OSGi 框架创建。只有当一个 Bundle 中的所有包约束条件都满足时,它才被正确解析完毕。

Bundle 解析

Bundle 的解析是通过分析定义在 MANIFEST.MF 文件中的元数据 ( 主要定义了包约束条件 ),查找与包约束条件相匹配的 Bundle 并建立关联关系的过程。 MANIFEST.MF 文件中的包约束条件主要是通过 Import-Package、DynamicImport-Package、Export-Package 和 Require-Bundle 这四种表达方式来实现。下面简单介绍一下它们:

  1. Import-Package:定义需要导入的包。默认是所有需导入的包必须都能够找到相应的导出 Bundle (Exporter),否则解析失败。
  2. Export-Package:定义导出的包。在一个 Bundle 里面,一个包的导出定义并不意味着相应的包导入定义,而是这些类资源会在 Bundle 自身的类路径里面查找和加载。
  3. Require-Bundle:定义依赖的 Bundle 。
  4. DynamicImport-Package:定义需要动态导入的包。这部分定义没有在 Bundle 解析过程中使用,而是在运行时动态解析并加载共享包。

在 Bundle 得到正确解析后,OSGi 框架将会生成此 Bundle 的依赖关系表。在实际运行过程中,框架就可以通过此关系表找到 Bundle 依赖的外部 Class Loader,从而实现外部类资源的加载和运行。

 

Bundle 运行

Bundle 的运行主要依靠于 OSGi 框架为其创建的类加载器(Class Loader),加载器负责查找和加载 Bundle 自身或所依赖的类资源。 ClassLoader 之间的依赖关系构成了一个有向图,如下图所示:


Class Loader 依赖关系图
图 2. Class Loader 依赖关系图 

Bundle 的 Class Loader 能加载的所有类的集合构成了 Bundle 的类空间 (Class Space) 。类空间包含的类资源主要来自于以下几个方面:

  1. 父 Class Loader 可加载的类集合;
  2. Import-Package 定义的依赖的包;
  3. Require-Bundle 定义的依赖的 Bundle 的类集合;
  4. Bundle 自身的类集合,通常在 Bundle-Classpath 中定义;
  5. 隶属于 Bundle 的 Fragment 类集合。

在实际运行环境中,Bundle 的 Class Loader 根据如下规则去搜索类资源。规则简要介绍如下:

  1. 如类资源属于 java.* 包,则将加载请求委托给父加载器;
  2. 如类资源定义在 OSGi 框架中启动委托列表(org.osgi.framework.bootdelegation)中,则将加载请求委托给父加载器;
  3. 如类资源属于在 Import-Package 中定义的包,则框架通过 Class Loader 依赖关系图找到导出此包的 Bundle 的 Class Loader,并将加载请求委托给此 Class Loader ;
  4. 如类资源属于在 Require-Bundle 中定义的 Bundle,则框架通过 Class Loader 依赖关系图找到此 Bundle 的 Class Loader,将加载请求委托给此 Class Loader ;
  5. Bundle 搜索自己的类资源 ( 包括 Bundle-Classpath 里面定义的类路径和属于 Bundle 的 Fragment 的类资源);
  6. 若类在 DynamicImport-Package 中定义,则开始尝试在运行环境中寻找符合条件的 Bundle 。

如果在经过上面一系列步骤后,仍然没有正确地加载到类资源,则 OSGi 框架会向外抛出类未 发现异常。

猜你喜欢

转载自guoxp.iteye.com/blog/1330530