spring-dm-reference.pdf阅读笔记（二）

在OSGi中，部署以及实现模块化的基本单位是Bundle，Bundle在运行环境中有三种状态——installed、resolved和active——Bundle可以向OSGi service registry导出服务，这样别的Bundle就可以查找并使用这些服务，当然也可以导出包，此时别的Bundle就可以导入包中的类型。

在Spring Framework中，最基本的单元是application context，其中包括一些bean，application context可以通过继承关系来配置，亦即，父application context中的beans对子application context是可以见的，但反过来却不可以。在Spring中，exporter与factory beans用于向在application context外的client导出指向beans的引用，也被用来注入在application context外定义的服务。

在Spring DM中，一个处于ACTIVE状态的Bundle包含一个application context，负责application context的初始化和配置，以及其中beans的组装及装饰，例如一些beans可能导出为OSGi services，一些beans可能注入了一些OSGi services的引用。

OSGi应用中很重要的一个模式是extender，即它允许别的bundle扩展某个特定领域的功能，鉴于此，Spring Dynamic Modules提供了一个bundle，org.springframework.osgi.extender，这个bundle很重要，首先，它负责我们应用程序Bundle中application context的创建，它与Spring web application中ContextLoadListener是一样的目的，一旦这个Bundle安装并启动以后，它就开始寻找处于active状态的Bundle，并相应地创建application context，而且，它会监听bundle started event，一旦某个新的bundle启动，就创建相应的application context。

Extender bundle创建application context的过程是异步的，创建application context的线程与start bundle的线程是不同的，这样保证了启动一个platform的速度足够快且不会发生死锁，看一下给出的图：

Extender监听STARTED event，然后将这个bundle传递给Spring DM的线程，由它来创建application context。

这里需要注意的是，extender只识别处于ACTIVE状态的Bundle，别的状态的Bundle将会被忽略掉。当然创建application context的过程也是可以同步的。

如果创建application context的过程失败，那么这个原因将会被log起来，但是bundle的状态还是处于ACTIVE，但是将没有任何services导出。

如果一个application context依赖于个必须满足的OSGi service，那么创建线程将一直阻塞，直到所有的依赖均得到满足。但是这个只能说明创建时所有的依赖都得到满足，但是可能某个依赖在创建的过程中又不满足了。但是一般的应用中，当platform启动起来以后，状态基本上是稳定的。可以设定一个强制依赖满足的超时时间，默认为5分钟，但是可以通过timeout这个属性来设定。一旦一个application context创建成功，那么这个application context object也将被导出为OSGi服务，当然也可以通过配置不导出这个服务。关于导出这个服务，最初的目的是为测试、管理，一般并不鼓励在运行时访问这个object以及调用getBean()或者类似的操作，最好的方法是将要访问的bean导出为一个OSGi服务。

当一个处于ACTIVE状态的bundle被stopped时，任何导出的服务都将被注销，此时bundle状态为RESOLVED，一个停止的bundle会释放它占有的任何资源，也会终止相关的线程，但是导出的包仍旧可以被其它bundles使用，处于RESOLVED状态的bundle可以被uninstalled，状态为uninstalled的bundle导出的package对已经导入了该package的bundle来说，仍旧可用，但对新start的bundle是不可用的。请看下图：

这是bundle之间状态的迁移。

关于PackageAdmin refreshPackages操作的影响，受到影响的bundle的application context都将被重启，而那些update过的bundle的老版本导出的包，以及那些uninstalled的bundle导出的包都将不可用。

当一个bundle被stop时，相应的application context将会被销毁，如果稍后又被start，那么一个新的application context会被创建。

接下来是Resource Abstraction，

如果没有prefix，那么默认的为osgibundle。

由于OSGi动态的特性，一个bundle的classpath可能会改变，当然通常的http:以及file:这些resource prefix也是支持的，只是这些resource没有必要必须在加载资源的bundle里面定义，有些platform可以定义自己的prefix来访问bundle的内容，但是这样的话，代码就是platform相关的。

一般来说，使用Spring Dynamic Modules，基本上没有必要再去访问BundleContext这个类，当然如果需要，Spring DM也提供了很好的方法。由Spring extender创建的application context自动包含一个BundleContext类型的bean，名字为bundleContext，可以将这个bean注入到任何其它需要的beans当中，同时Spring DM提供了一个接口BundleContextAware：

任何实现这个接口的bean都将注入了一个指向bundleContext的引用。

与创建application context不同的是，销毁application context是以同步的方式进行的：

这是必要的。

当stop the extender bundle时，它创建的所有application context都将被销毁，以一种可以管理的方式进行。

这是Chapter 5的内容，错误之处，恳请指正。

Best Regards

胡靖飞