OSGi基础接口

BundleContext-Bundle上下文

  • installBundle 自定义Bundle装载用,例如Apache Felix Install/Equinox Configurator等Bundle扫描和安装插件都使用此方法。
  • getServiceReference 获取服务引用,不推荐使用,用ServiceTracker代替
  • getService 获取服务
  • getBundles 获取所有Bundle
  • getBundle 获取持有当前上下文的Bundle
  • getBundle(long bundleId) 根据id获取Bundle

BundleActivator-Bundle激活器

  • 仅用于简单的Bundle注册个别服务,如数据源Bundle,缓存服务Bundle等
  • 强烈不推荐在业务开发的过程中使用
  • 使用OSGi Declarative Service/Apache jPOJO/Apache Aries Blueprint/Gemini Blueprint等第三方框架代替
  • 使用BundleActivator应注意,不可在star/stop方法内执行复杂逻辑,应尽快完成,并且不能阻塞,否则将导致其他Bundle启动进行排队

Bundle

  • getBundleContext 获取上下文,你想一个Bundle访问其他Bundle时使用
  • loadClass

    • 加载本Bundle的类,该方法经常被用来实现BundleClassLoader
    • 扩展点,配置BundleTracker/Javassist/JDK注解来完成Bundle启动时标记了特定注解类的加载,已达到扩展的目的。例如扫描标记了@RunWith的测试用例并启动
  • start/stop

    • 启动和停止,Bundle务必处于Resolve状态才可以start,可用PackageAdmin的resolveBundles来解决依赖
    • 扩展点,配合PackageAdmin和BundleContext,可实现任意Bundle在运行时的API方式启动,甚至是字节数组定义
  • getHeaders

    • 获取MANIFEST.MF文件内定义的所有key/value键值对
    • 扩展点,在MANIFEST.MF文件中定义的自定义属性可以被读取。配合BundleTracker可以识别添加了指定属性的Bundle
  • getResource 获取Bundle内的资源
  • findEntries

    • 查找Bundle内的资源,强烈不推荐使用,在开发环境中会发生无法找到资源的情况
    • 使用BundleWiring.listResource代替
  • adapt 使用bundle.adapt(BundleWiring.class)的方式获取BundleWiring

BundleListener/ServiceListener

  • 不推荐使用
  • BundleListener无法监听在其注册之前启动的Bundle
  • ServiceListener无法监听在其注册之前启动的Bundle
  • 使用BundleTracker/ServiceTracker代替
  • BundleTracker可以监听所有Bundle,即使是BundleTracker注册之前启动的Bundle,依然可以监听到
  • ServiceTracker可以监听所有的服务

ServiceRegistration

  • 手工反注册服务使用,通常 用于框架性质的代码,不常用
  • 不推荐普通用户使用

ServiceReference

  • 服务引用
  • 获取服务之前,必须先拿到该引用
  • 可以通过BundleContext.getServiceReference()或ServiceTracker.addingService方法获取

PackageAdmin-包管理

  • 该接口已过时,但其在OSGi 4.x规范中不会被舍弃
  • 其提供的部分方法在其他接口中没有代替
  • getExportedPackages 获取某个Bundle的导出包
  • refreshPackages 刷新包
  • resolveBundles 解决包依赖,API方式安装Bundle后,在其启动前必须调用该方法
  • getFragments 获取子Bundle,一旦拿到,就可以读取子Bundle的MANIFEST.MF文件,可以读取配置/加载接口实现等等

标签: Java, OSGi

添加新评论