Java 开发平台中
对于组件开发过程比如打包、部署和验证等并没有
个统标准
正因如此许多 Java 项目例如 JBoss 和 Net Beans都拥有套自定义组件开发规范标准和框架但是实际上这些解决方案都是基于为组件分配独立类加载器 (Class Loader) 思想 OSGi 框架为基于 Java 组件开发提供了套通用和标准解决方案并已经成为事实上工业标准OSGi 组件框架
在 OSGi 框架中
组件被称为 Bundle它是由些提供 Bundle 自身功能资源 ( 如 Java 类文件、配置文件等 )、MANIFEST.MF 文件和其它资源文件构成在运行时环境中每个 Bundle 都有个独立 Class LoaderBundle 的间通过区别类加载器和在 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 这 4种表达方式来实现下面简单介绍下它们:Import-Package:定义需要导入
包默认是所有需导入包必须都能够找到相应导出 Bundle (Exporter)否则解析失败 Export-Package:定义导出
包在个 Bundle 里面个包导出定义并不意味着相应包导入定义而是这些类资源会在 Bundle 自身类路径里面查找和加载 Require-Bundle:定义依赖
Bundle DynamicImport-Package:定义需要动态导入
包这部分定义没有在 Bundle 解析过程中使用而是在运行时动态解析并加载共享包 在 Bundle 得到正确解析后
OSGi 框架将会生成此 Bundle 依赖关系表在实际运行过程中框架就可以通过此关系表找到 Bundle 依赖外部 Class Loader从而实现外部类资源加载和运行 hg Bundle 关系图可以在 OSGi 控制台中通过内部命令＂ bundle ＂来查看如下图所示:图 1. Bundle 依赖关系表
Bundle A 向外 Export 两个包 p 和 r
其中 p 对 q 存在约束关系即 q 须为 Bundle B 中 1.0 版本同时Bundle C 又分别导入了 p 和 q 两个包包 p 来自于 A而包 q 为 Bundle D 中 2.0 版本虽然 C 中并没有显示地定义对 B 中包 q 依赖关系但是由于 A 中包 p 绑定了 B 中版本为 1.0 包 q故 C 在解析对包 p 依赖关系时候也会自动把 B 中 1.0 版本包 q 导入到自己类空间中这样在 C 类空间中就存在着两个区别版本、来自于区别 Bundle 包 q进而就会存在两个区别 Class Loader 对应着包 q故在 Bundle C 运行过程中就会出现类不致性异常小结
本文介绍了 OSGi 框架
组件运行机制包括 Bundle 解析、运行等并结合实际举例演示了在基于 OSGi 平台开发 Bundle 过程中应该注意些问题
最新评论