Spring+OSGi规范

1.0 简介 Spring 框架是一个领先的 full-stack Java/JEE 应用框架。它提供一个轻 量级的容器，依赖注入、aop、可插接的服务抽取，这些使得非侵入式的编程模 型成为可能。OSGi 提供了一个动态应用程序的执行环境，在这个环境中组件 （bundles）可以在运行中被安装、更新、删除。它同时也可以很好地支持模块 化及版本化。 Spring’OSGi 的目标是使得写基于 Spring 的应用程序尽可能的容易，这些 应用可以部署到 OSGi 的执行环境中，并可有效利用 OSGi 框架所提供的服务。 通过在易用、强大的 Spring 框架上构建应用程序，Spring 对 OSGi 的支持也 使得开发这样的基于 OSGi 的应用更加简单、更加高效。 • 更好的分离应用逻辑与模块； • 同时部署一个模块的多个版本的能力； • 动态查找、使用系统其它模块提供的服务的能力； • 在运行时系统中动态部署、升级、卸载模块的能力； • 使用 Spring 框架在模块之间实例化、配置，集成，装饰组件； • 让企业应用开发者使用简单、熟悉的编程模型开发 OSGi 平台的功能。 我们相信 OSGi 与 Spring 的结合为构建企业应用提供了最全面的可用的模 型。 Spring’s OSGi 的目标并不是提供一个通用的模型以支持任意的基于 OSGi 的应用程序开发，但是某些 OSGi 的开发者肯定能够发现 Spring 模型吸引人之 处，并采纳它。目前已经存在的 OSGi 的 bundles 以及它们所 export 的任何 服务都可以轻松的集成到使用 SpringOSGi 支撑的应用中，就象是 Spring 已经 存在的配置项。 Spring OSGi 定位于 OSGi R4 及以上版本，JDK1.3 及以上版本。 这个 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 假设读者已经具有一定的 Spring 及 OSGi 的知识。参见介绍白皮 书“OSGi for Spring developers”以及“Spring for OSGi developers”。 注意：这些白皮书现在还不存在，还处于书写阶段，吼吼吼。 2.0 Bundles and Application Contexts OSGi 中的开发单元（以及模块单元）是 bundle。OSGi 中所说的 bundle 有三种稳定状态：installed，resolved，active。Bundles 可以导出（export） 服务，其它的 bundles 可以查找并使用这个服务。 在 Spring 中主要的模块化单元是一个 application context，它包含很多 个 beans（由 Spring 应用环境所管理的对象）。Application contexts 可以 分级配置，这样一个子 application context 可以看到定义在其上级的 beans， 但是反之则不行。Spring 的 exporters 及 factory beans 的概念用于导出引 用给 application context 外部的客户端的 beans，以及注入引用到定义在一 个 application context 外部的服务。 OSGi 的 bundle 与 Spring 的 application context 有着本质的联系：一 个激活的 bundle 可以包含一个 Spring 的 application context，负责在 bundle 中实例化、配置、组装以及装饰对象（beans）。其中一些 beans 可以 被导出(export)为 OSGi 服务以供其它 bundles 使用，在 bundle 中的 beans 也可以被轻松的注入 OSGi 服务引用。 2.1 在 Bundle 中创建 Application Context 一个 Application context 可以使用一个或多个定义了 beans 的 XML 配置 文件来配置。（严格地说，一个 application context 对于配置的形式并不可知， 但是 XML 是最常用的形式）。包含配置信息的 XML 文档放置于 bundle 中的 META-INF/spring 文件夹。缺省情况下，Spring 将使用在这个文件夹中的所 有以“.xml”为扩展名的文档，作为 application context 的配置定义。 缺省设置可以在 Spring-Context 的 manifest header 中重写。Header 的值是由逗号分隔的资源路径及指令列表。 Spring-Context ::= context ( ’,’ context ) * > context ::= path ( ’;’ path ) * (’;’directive) * 每一个路径都被当作在 bundle 中定义的资源路径处理，例如： Spring-Context: config/application-context.xml,config/security.xml 当带有 Spring-Context manifest 入口文件或者位于 META-INF/spring 文件夹中的资源的bundle被激活时，Spring将自动创建application context。 为了达到这一点，你必须首先安装（install）并启动（start）在你的 OSGi 运 行时中的 org.springframework.osgi.extender bundle。 当一个 application context 被首先创建后，它就判断所配置的 OSGi 服务 引用，看是否有任何服务引用指定了 cardinality（例如指定 1..1 或者 1..n）。 直到所有必须的服务都可用之后，这个 context 的初始化才结束。 wait-for-dependencies指令可以在Spring-Conext头中设置为 false从而改 变这种行为。当 wait-for-dependencies 设置为 false 时，如果 application context 在被激活时其所必须的服务还不可用，创建 application context 将失 败。 清单头条目（The manifest header entry）： Spring-Context: *;wait-for-dependencies:=false 表示所有在 META-INF/spring 中的 xml 文件都应该被配置，并且如果 context 所必须的服务不是立即可用，context 的创建将会失败。 A header entry: Spring-Context: config/application-context.xml;wait-for-dependencies:=false 表示使用 config/application-context.xml 配置文件来配置 application context，并且如果其所必须的服务没有立即可用，context 的创建将会失败。 Application context 作为 org.springframework.context.ApplicationContext的一个实例被自动发布 为一个 OSGi 服务。此外，org.springframework.context.service.name 用 于设置驻留了 application context 的 bundle 的标识名称。通过在 Spring-Context manifest entry 中指定“publish-context:=false”可以禁 止发布 context 为一个服务。 注意：application context 被发布为一个服务使得测试和管理变得容易。获取 一个指向在其它 application context 中定义的 bean 的首选方式是使用 和 元素（相对于在 application context 服务中调用 getBean()方法）。原因就在于通过使用 和 组成服务，OSGi 的基础架构将保证一 个 bean 只能看到类的版本与之相兼容的服务，反之如果在注册表中查找一个 application context，然后调用 getBean(…)返回一个对象，然后类兼容性的 唯一保证就是 ApplicationContext 类自身是兼容的。很明显在一个存在同时部 署了多个版本的 bundle 的系统中，这种保证是不够健壮的。 2.2 Spring 资源抽取 Spring 在 application context 中使用 Spring ResourceLoader 加载资 源。相关资源路径由 application context 以一种与 application context 类型 相符的方式（例如基于 context 的 class path，或基于 context 的 web-app） 解释。对 OSGi 应用来说，相关资源路径作为从 bundle classpath 中加载的资 源解释。如果资源路径以“bundle:”前缀开头，那么只以给定的资源搜索 bundle 自己及其附加的 fragments。 2.3 BundleContextAware Spring 鼓励基于不依赖于任何环境的简单对象开发应用。但是，如果一个 Spring bean 由于某种原因的确需要访问它的 BundleContext，那么这个 bean可以实现org.springframework.osgi.context.BundleContextAware 接口。实现这个接口的 Bean 当在 application context 中实例化时将会被注入 BundleContext。 2.4 使用 Context ClassLoader 目前存在很多很有用的第三方包及应用，它们对 OSGi 一无所知，并且依靠 线程环境 ClassLoader 动态加载类。OSGi 没有定义 context 类加载器在任何 时间点将是什么（OSGi does not define what the context ClassLoader will be at any point in time.）。这个现实与 OSGi 的非分级的类加载机制相符， 意味着这些包将不能找到它们所需要的类和资源。 举一个简单的例子，一个应用被打包到 bundle A 中，使用 bundle H 所导 出的 Hibernate 的类创建了一个 Hibernate SessionFactory。这个 SessionFactory 将会需要加载定义在 bundle A 中的应用的类及资源，但是对 于它来说，在 OSGi 环境中，bundle A 是不可见的。为解决这个问题，Context ClassLoader 对于任何从 bundle A 发起调用到 bundle H 的线程来说必须被 设置为 A 的 bundle ClassLoader。 Spring-OSGi 保证了当激活一个 bundle 时，context ClassLoader 总是 被设置为能够访问被激活的 bundle 的资源。这样在 bean 实例化及配置阶段发 起的对包的调用总是产生于一个合适的 context ClassLoader 的上下文环境 中。 请求 Spring 管理 context ClassLoader 调用 OSGi 服务也是可能的，以 及对作为 OSGi 服务而暴露的 beans 的调用。想了解更多的细节请参考第三部 分。 2.4.1 Other contexual access Spring bean能够实现BundleContextAware接口以方便被注入它所在的 bundle 的 BundleContext 引用。在 bundle 被激活以及其它调用某个被当作 Spring bean 访问的 OSGi 服务时，Spring 也会通过一个 ThreadLocal 变量 来提供对“当前”bundle 的 BundleContext 的访问，这个变量可通过 LocalBundleContext.getContext 获取。 2.5 Web 应用支持 Spring 使用 ServletContextListener， org.springframework.web.context.ContextLoaderListener 来自动的为 web 应用创建 WebApplicationContext。OSGi 可用的 WebApplicationContext， org.springframework.osgi.context.support.WebApplicationContext 版本提 供用来在 OSGi 中运行 web 应用。要使用这种支持，需要在你的 web.xml 文 件中设置监听器声明的 contextClass 参数为 “org.springframework.osgi.context.support.WebApplicationContext ”。 3.0 OSGi 平台服务和动态本质 OSGi 是一个动态的平台：bundles 可能在框架运行期的任意时刻被安装、 启动、更新、停止以及卸载。在本章我们将从 application context 及其发布和 访问的服务的角度来揭示这意味着什么。 当一个激活的 bundle 停止时，在它的生命周期中它所导出的任何服务也将 被自动反注册，并且 bundle 返回到 resolved 状态。停止的 bundle 会释放所 有它所获取的资源，终止所有的线程。停止的 bundle 所导出的 Packages 仍然 对其它 bundles 可用。 处于 resolved 状态的 bundle 可以被卸载：被卸载的 bundle 所导出的 packages 也仍然对其它导入它们的 bundles 可用（除了新安装的 bundles）。 处于 resolved 状态的 bundle 也可以被更新。更新使得 bundle 从一个版 本迁移到另一个版本。 最后，处于 resolved 状态的 bundle 可以被启动，使它的状态转移到 active 状态。 OSGi PackageAdmin refreshPackages 操作刷新所有 OSGi 框架的包或 者是已安装的 bundles 的给定的子集。在刷新期间，受其影响的 bundle 中的 application context 将会被停止并重新启动。refreshPackages 操作完成后， 被更新的 bundle 的原有版本导出的包不再可用。完整的细节内容请参考 OSGi 规范。 3.1 启动停止定义了 application context 的 bundle 当包含 Spring 资源的 bundle 被激活时，这个 bundle 的 application context会自动创建（参见2.1节）。随后，当这个bundle被停止时，application context 会被关闭然后销毁。在 context 中任何实现了 DisposableBean 接口 的单例 bean 或在配置中指定了 destroy-method 的 bean 将会收到通知。当 application context 停止后，所有被 bundle 导出的 OSGi 服务会被反注册。 3.2 OSGi 服务 OSGi 服务是一个在 OSGi 服务注册表中发布的对象，提供公开的接口。服 务也可以发布成为一组可查询的属性。 OSGi 服务本质上是动态的因此使用服务的应用需要有这方面的处理机制。 OSGi 提供几种不同的机制来处理动态服务，包括声明性服务（DS）规范。 使用 DS 时，服务组件的所有依赖都满足后被激活，服务组件也可以用一些 简单的属性值（简单类型，字符串值以及这些类型的数组或 vectors）和引用已 发布的 OSGi 服务进行配置。组件自身也可能以一个由它自己所指定的接口实现 作为 OSGi 服务注册。 服务组件类似于 Spring beans，因为它们由简单 Java 对象返回并且可以 进行依赖注入。然而，与 Spring 相比，这种依赖注入是非常有限的，没有任何 在 Spring 中的 bean 可以使用的更高级功能的支持，例如 AOP，声明性事务， 安全，管理，导出/导入其它的非 OSGi 服务等等。而且如果不以完全的 OSGi 服务的形式导出任何注入的服务引用，也不可能将这组服务组件与某个 bundle 进行组装（It is also not possible to assemble together a set of service components within a bundle without also exporting any injected service references as full OSGi services.）。Spring 允许在一个 bundle 中对 bean 进行完全的配置与组装，而且不需要仅仅为了在相同 bundle 中的另 外一个 bean 的需要就将 bean 导出到 bundle 之外。这样在导出（exported） bean 与私有（non-exported）bean 之间就有了明显的区别。 DS（相当合理地）要求服务以 OSGi 服务组件形式打包，并使用 OSGi 的 语法进行配置。当使用 Spring 的 OSGi 时，对用户来说这是一个潜在的混淆， 因为在 DS 的概念、语法与 Spring beans 之间存在重叠。 Spring-OSGi 能够管理在 Spring application context 中声明的服务之间 的依赖关系，并且支持与 DS 相同的延迟激活语义。Spring 也完全支持动态的 发布、访问服务。Spring-OSGi 使得 bundles 能够与使用 DS 的 bundles 和 谐共存，但是对于新的 bundle 的开发来说，我们推荐使用 Spring OSGi 来代 替 DS。 Spring 目的是提供一种简单、一致的编程模型，无论是在 OSGi 环境之内 还是之外。这方便了在 OSGi 之外的测试工作，使得不熟悉 OSGi 的复杂编程模 型的企业 Java 应用的开发者更容易、更高效地进行测试。同时，如果一些高级 功能的确需要直接与 OSGi 协同工作，这也是支持的。 3.3 使用 OSGi 服务 元素用于定义一个本地的 bean 代理某一个（或一组） OSGi 服务。唯一需要的属性是 id（定义本地 bean 的名字）和 interface（定 义目标服务所注册的接口的全质类名）。 例如，定义一个本地 bean 代表 MessageService 服务： filter 属性能用来指定一个可选的 OSGi 框架过滤器表达式来限定一组目标 服务。 可选属性 depends-on 保证了所声明的依赖在引用 bean 之前被实例化。 可选的 cardinality 属性允许指定引用集（cardinality）（0..1，1..1，0..n， 1..n）。缺省是“1..1”。当指定 cardinality 为 0..1 或者 1..1 时， 元素将 interface 元素所指定的接口类解析为一个 bean。 当指定 cardinality为 0..n 或者 1..n 时，元素将 interface 元素解析为一个接口类元素的集合。 请看下面的配置片段：       类“SomeClass”定义如下： public class SomeClass {   private MessageService msgService;   private Collection listeners;   public void setMessageService(MessageService aService) {     this.msgService = aService;   }   public void setEventListeners(Collection listeners) {     this.listeners = listeners;   }   // ... } 注意：也可以使用原生类型 Collection 替代集合， Spring-OSGi 不要求必须使用 Java5。 3.3.1 绑定/反绑定服务资源 Spring 给你一个常量对象引用，由定义（可以是一个 指定为 0..1 或 1..1 的指向目标服务的代理，也可以是一个指定为 0..n 或 1..n 的 Spring 所管理的集合）。这个引用背后的服务可以动态的来去。 对于持有一个集合的服务引用来说，调用 iterator()操作会返回一个 Iterator 实例，可以遍历某个常量引用集（在调用 iterator()时匹配的引用）。 集合成员可以在任何时间发生改变，因此再次遍历集合会看到不同的成员。 在任何时刻调用某个服务引用的操作都可能会失败，抛出一个 unchecked （译者注：这里应该是指不用捕获的运行时异常的意思）异常。通过指定 的 timeout 属性，Spring 可以配置为等待指定毫秒数，以 使某个服务在失败之前变成可用。如果所要求的服务不可用，默认的行为不是立 即失败（例如没有延时期）。 例如： 对于可选的服务引用（那些带有 cardinality 为 0..1 或 0..n 的服务引用）， 属性 oneway 可以设置为“true”。如果目标服务不可用，那么通过 cardinality0..1 的服务引用发起的、且返回类型声明为空的操作的调用将不会 抛出 ServiceUnavailableException 异常。同样，如果这些操作声明返回类型 为空并且目标服务在操作调用之前不可用，对通过遍历 bean cardinality 0..n集合而获取到的某个服务引用的操 作也不会抛出 ServiceUnavailableException 异常。 对于无状态的服务，支持到这种级别应该足够了。操作调用之中或之间，目 标服务可能会被透明的更新。如果当调用应用时目标服务不可用，服务可以被重 试，如果还不可用，唯一的可能就是抛出 ServiceUnavailableException 异常。 对于有状态的服务，或者对于仅仅想加入到服务跟踪链的客户端，通过使用 嵌套 listener 元素指明一个或多个监听器，是有可能清晰的跟踪到 OSGi 服务 支持的服务引用（OSGi services backing a service reference）的可用性的。       如果 bind-method 和 unbind-method 属性都没有指定，那么被监听器引 用的 bean 的类名必须实现 Spring 的 TargetSourceLisfcycleListener 接口。 如指定了 bind-method 或者 unbind-method 属性，那么它们的属性值必须 是监听器 bean 类的一个方法的名字。当一个 backing service 被绑定或反绑 定时，Spring 将会调用所声明的方法。 声明绑定或反绑定操作如下所示： public void some-method-name(String serviceBeanName, service) public void some-method-name(String serviceBeanName, Object service) public void some-method-name( service) public void some-method-name(Object service) 当绑定方法被调用时，serviceBeanName 参数（如果使用了）传递 绑定的 bean 的名字（例如“messageService”）。service 参数是代理目标服务的（不变的）服务引用。无论何时更新目标服务，包括初始 化目标服务绑定，绑定方法都将会被调用。 每次服务从 tracked reference 集合中增加或删除时，为带有 cardinality 0..n 或者 1..n 的元素定义的监听器都会被调用。 Spring 将延迟创建非可选服务引用（带有 cardinality 1..1 或 1..n 的 的 beans）的 application context，直到那些引用被满足。 但是，如果 application context 的非可选服务依赖变成不再被满足，Spring 也不会自动销毁 application context。如果某个服务的功能对于 application context 来说真的很重要以致于 context 没有它就不能继续，那么可以让这个 服务引用的某个监听器 bean 实现 ConfigurableApplicationContextAware 并且在它的 unblind方法中调用被注入的 application context对象的 refresh 方法。调用 refresh 将会销毁所有的 application context 中的可任意处理的 bean 并且使得一旦非可选服务引用重新满足时 application context 被再次刷 新。 3.3.2 通过服务工厂获取服务引用 OSGi 服务可以由 ServiceFactory 返回。当某个服务由服务工厂提供时， 每个请求引用这个服务的 bundle 都会获取唯一属于它们自己的服务实例。为支 持由工厂创建服务的客户端配置，Spring 支持嵌套在中的 property 元素。某个支持服务引用的目标服务将会由 Spring 依赖注入这个给 定的属性。注入发生于每次目标服务被绑定到服务引用上时。 注意：我们不鼓励使用带有不是由 ServiceFactory 返回的服务的嵌套属性元 素。我们的理想是制止这情况，但是 OSGi 没有提供足够的关于服务的运行时元 数据。 3.3.3 Context ClassLoader 管理 OSGi 没有定义当一个客户端 bundle 调用另一个 bundle 发布的服务上的 操作时，哪些类型是通过 context 类加载器可见的。（注意：OSGi 规范未来的 版本在这一点上可能会有些保证）。对许多希望使用 context 的类加载器加载 类与资源的企业包来说，保持 context 类加载器不被定义是不可接受的。 可以使用元素的 context-classloader 属性来控制对 context 类加载器的管理。缺省值是 client，指明的行为如上所述。将其值设置 为service-provider可以保证当操作被调用时ContextClassLoader在服务提 供 bundle 中对类与资源可见。将其值设置为 unmanaged 意味着 Spring 根本 不会试图管理 context 类加载器。 3.4 将 Spring beans 导出 OSGi 服务 任何在 application context 中定义的 bean 都可能被导出（注册）为一个 OSGi 服务。当 application context 停止时它也将被自动反注册。 一个 bean 使用元素注册为 OSGi 服务。ref 属性命名了这 个被注册的 bean，interface 属性定义 bean 注册的接口类型。例如： 元素可以有选择的包含一个或多个嵌套的 service-property 元素，这些元素定义注册这个服务时所使用的属性。 除了引用对被 reference 导出的 bean 的之外，它也可以定义为 元素的匿名内部 bean。例如：            如果 lazy-init 属性被设置为 true，那么这个服务将直到它被引用到才会创 建。 如果作为服务导出的 bean 实现了 OSGi ServiceFactory 接口，那么 OSGi 将会调用这个接口所定义的方法以保证每一个请求服务的 bundle 获取唯一属 性自己的服务实例。 Bean 可以实现 Spring 的 FactoryBean 接口，代替实现 OSGi ServiceFactory 接口。如果工厂 bean 的 singleton 属性被设置为 true，则服 务的所有客户端都将看到相同的服务实例，但服务自身直至它被引用时才会创 建。如果 singleton 属性设置为 false，则每次 bundle 请求时，工厂 bean 的 getObject 方法都将会调用一次。如果由非单例工厂的 getObject 方法所返回 的服务对象实现了 DisposableBean，那么当所有引用这个服务对象的关联 bundle 都被释放后，服务对象的 destroy 方法就会被调用。 3.4.1 Context ClassLoader 管理 OSGi 没有定义当执行一个服务方法时，哪些类型对于 context ClassLoader 是可见的。（注意：OSGi 规范未来的版本在这一点上可能会有些 保证）。Spring 可以为在中定义的 bean 的操作管理 context ClassLoader。元素支持 context-classloader 属性，这个属 性缺省设置为 unmanaged（Spring 不会为此服务的方法执行任何其它 context ClassLoader 的管理）。设置这个属性为 service-provider 可以让 Spring 保证当执行这个服务时，通过 context ClassLoader 可以使用发布服 务的 bundle 的类与资源。 注意:设置 context-class-loader=“service-provider”将会覆盖任何 context ClassLoader，而这个 ClassLoader 可能已经被设置到通过 所定义的 bean 发起的服务的调用上。 4.0 OSGi 配置管理服务 Spring 支持从 Spring 配置文件来设置 bean 属性值，并且支持从不同的来 源来检索这个值。例如，Spring PropertyPlaceholderConfigurer 类可以用 于将 escaped 属性值替换为从属性文件中加载的值。 Spring OSGi 也额外提供了从 OSGi Configuration Admin Service 中追 溯 bean 属性值的来源。要做到这点，需要在 Spring 配置中定义一个或多个 propertyPlaceholder 元素（若多于一个，每一个都要用一个唯一的分隔符字 符串进行配置）。例如：    其中“persistent-id”是 OSGi PID，用作配置数据的关键字。默认分隔符 是“${…}”，这样像例如带有值“${timeout}”的属性的值将被替换为配置 管理服务在所提供的 PID 下持有的“timeout”属性的值。如果“update”属 性设置为 true，那么通过管理服务修改配置设置时，单例 beans 将被重新注入 新的属性值。重注入仅支持基于方法（而非构造函数）的注入。 可选的 default-properties 属性可被设置为一个（java.util.Properties 或者 java.util.Map 类型的）bean 的名字，如果配置管理服务没有相匹配的定 义被引用属性，这提供了默认的属性值。 参考Spring osgi schema获取property-placeholder元素的全部详细内 容。 4.1 原子更新 如果通过配置管理服务设置了 Bean 的多个属性，并使用了“update”， 当对配置进行一系列相关的修改时这个 bean 将能看到多个属性更新（每一个更 新针对一个属性变化）。 元素定义了一个 Map 类型的 bean，包含所有在 persistent-id 中注册的属性。    它支持零个或多个嵌套 config-listener 元素，用于定义监听器 beans，当 Map 的内容发生变化时，这些 beans 将得到通知。config-listener 的 update-method 属性是必填的。这个属性的值是当配置发生改变时要调用的被 引用监听器 bean 的方法名。例如：            update-method 属性中命名的方法必须符合以面的形式之一： public void update_method_name(java.util.Map properties) 或 public void update_method_name(String pid, java.util.Map properties) 第二种形式是为使用 managed service factories 准备的（参见 OSGi 服 务纲要 104.6 节）。如果元素所指定的 persistent-id 实际是 一个 ManagedServiceFactory 所管理的配置信息的工厂 PID，那么 update-method 将在每次每组属性在工厂 PID 中注册时被调用。 5.0 安装与启动（Provisioning） OSGi 不会自动的安装并启动为其它 bundle 提供服务的 bundle。Spring 为创建一个用于安装、启动的 bundle 提供了基本的支持。在将来可能会实现更 复杂的安装启动功能（也许会与 Felix 的 OBR 结合）。 osgi:bundle 以及 osgi:virtual-bundle 配置元素定义了代表 OSGi bundles 的 beans。因此，基本的安装启动服务可以实现如下： 1. 安装并启动 OSGi Spring 的扩展 bundle 2. bean declarations 使用声明了的 application context 配置文件安装并启动一个“Spring”bundle 根据这一点，Spring 将管理其余所需要的 OSGi bundles 的 bring-up。 5.1 osgi:bundle 元素 元素可以用于为 application context 定义 bean，来代表 其它的 osgi bundle（这样的 bean 的类型为 org.osgi.framework.Bundle）。 可用的最简单的形式如下：   如果 location 属性也被设置，则这个 bundle 还未被安装的话，就会被安装。 如果“start”属性设置为 true，那么这个 bundle 还未启动，也就会被启动。    5.2 虚拟 bundles 支持基于 jar在运行时创建bundles。这种 virtual bundle 的机制允许用户熟练操作所有由 OSGi 解释的 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 headers。例如：                 com.me.bundles.bundleA                          com.me.bundles.bundleB            location 属性也允许是一个 maven 的 pom.xml 文件，从这个文件的 pom 以及根据 pom 中的信息访问到的相应的 jar 中将能够提取合适的版本信息。 5.3 未来安装与启动（Provisioning）的支持 根据哪些 bundle 导出哪些包提供哪些服务，可以提供一份清晰的列表，列 出被安装和启动的 bundle。将来安装启动（provisioning）可能会提供判断某 个 bundle 所需要的（导入的）包的实现，以及 bundle 所引用的服务，自动安 装启动所遇到的那些需要的 bundles。这些支持超出了本版本的范围。 6.0 集成测试 Spring 框架向来提倡测试驱动开发，并使得写出好的单元测试及集成测试 用例变得更容易。OSGi 应用程序的单元测试没有特列的要求，仅仅独立的测试 你的应用类。一个应用程序可以对 OSGi 没有任何依赖。如果有，例如， BundleContextAware，那么可以使用 OSGi Bundle 和 BundleContext 接 口很容易的进行模拟。 对于集成测试（在 OSGi 环境中执行测试），我们需要一些测试助手的帮助。 所推荐的最好的实践是在一个分离的测试 bundle中为要测试的 bundle开发集 成测试包。例如，给定一个 bundle“com.xyz.myapp.service”，你可以选 择把集成测试放到“com.xyz.myapp.service.tests”bundle 中。Spring 将 提供一个 AbstractOsgiTests 基类，以便于启动 OSGi 测试，安装、启动运行 一个测试所必须的 bundles。这保证了每个测试都运行在一个干净的 OSGi 环 境中，并且允许基于 OSGi 提供者的任何的支持来轻松的运行测试（我们将看一 看 equinox，knopflerfish 以及 Felix）。OsgiAdapter 接口将支持不在这个 范围之内的其它的 OSGi 提供者的加入。 更正：Knopplerfish 为 OSGi 提供了全套的集成，似乎适用于任何需求， 并且不必绑定在 Knopplerfish 实现。可以采用它做为集成测试工具。请参考 Knopplerfish 测试支持。 注意 Eclipse IDE 极好的支持基于 bundle 的测试，但是它绑定于 equinox 和 Eclipse IDE，而 Spring 需要支持更多的 OSGi 提供者，更多的 IDEs,并且 要支持基于 maven 和 ant 的持续集成。 7.0 使用 Spring 与 OSGi 开发 Web 应用 Martin Lippert 和 Gerd Wutherich 已经有了 Spring OSGi 代码在 web 应用中运行的沙盒，web 应用可以使用嵌入到 equinox 中的 servlet 容器，由 服务器方 equinox 孵化器工程（server-side equinox incubator project） 创建。Spring OSGi 工程目标在于企业应用，其中 web 应用的形式是很重要的 一部分。因此可以确认在底层基础设施的支持下我们能够更容易的使用 OSGi 来编写、部署 Spring 的 web 应用。这种支持最初将基于 equinox 孵化器，然 后如果可能的话，放宽到支持其它的 OSGi 提供者。 将开发一个简单应用，展示对在实际 web 应用环境中工作的支持。 8.0 管理 OSGi 应用 对于企业应用来说，通过 JMX 来管理 OSGi 的环境是很值得期待的（列出 bundles，安装/卸载/启动/停止/更新等等）。如果这种支持预先并不存在（反 正我还没有找到），那么Spring将提供一个OSGi bundle能够使用Spring JMX 的支持进行基于 JMX 对 OSGi 的管理。 9.0 将 Spring 打包为 OSGi bundles 要支持基于 OSGi 的 Spring 应用的开发，必须将 Spring 自身转换为一组 OSGi bundles（jar 文件）。这意味着 Spring jars 中将要确保存放所有必须 的 manifest entries。这个工作将在 Spring 2.1 中完成。每一个 jar 都将在 Spring 发布的“dist/modules”中被转换为一个有效的 OSGi bundle（使用 在 OSGi 环境之外的 OSGi manifest entries 也是无妨的）。新的监听器 jar 也将提供已描述的功能。 无论在什么情况下，所有资源加载与类加载都应该使用 bundle classloader，而不是 context classloader。当一个 application context 在 OSGi bundle 中创建时，这个 bundle 的 classloader 被设置为 application context 的 classloader，并且 ApplicationContext 所支持的 ResourceLoader 接口也已经在 OSGi 顶层服务中实现。 10.0 将 Spring 应用部署到 OSGi 环境 TODO：描述 maven plugin/ant task/SpringIDE 扩展，允许容易地打包 一个 Spring 应用为一个或一组 OSGi bundle。 附录 A. 将已存在的应用代码部署到 OSGi 在对 jar 文件进行最小的修改（intervention）转换为有效的 OSGi bundles 之后，将已存在的应用代码（特别是框架或包）部署到 OSGi 环境中是有可能的 （例如有 ant 和 maven tasks 来协助完成这项工作）。因为类加载以及 OSGi 的隔离属性不同于在企业应用中所遇到的典型情况，这引起一系列要注意的问 题： • META-INF 中的资源不能通过类加载器跨 bundle 直接访问。Spring 的 资源加载提取为基于 Spring 的资源加载解决了这个问题，处理规则如下： > 1.找到被发起请求的 bundle 所导入的所有导出包的宿主 bundles（通 过 PackageAdmin 服务完成）。 > 2.将对每一个 bundle 的请求代理给 Bundle.getEntry > 3.聚合并返回结果。 • 框架或者包不能依赖于 context 的类加载器获得对应用类的可见性。这 导致如果一个包试图通过反射加载一个应用的类，会出现 ClassNotFoundExceptions。在 equinox 中 ContextFinder 机制提供了 这个问题的解决 办法 鲁班奖评选办法下载鲁班奖评选办法下载鲁班奖评选办法下载企业年金办法下载企业年金办法下载 （work-aroun