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

添加新评论