spring+osgi 动态模型二; 打包和部署基于Spring的OSGi应用程序

部署一个应用程序到OSGi，更自然的结构是把应用程序打包成一系列的bundle（应用程序上下文），这些bundle通过服务注册表进行交互。独立的子系统应该被打包成独立的bundle或者一系列bundle（垂直划分的）
1、Bundle格式和Manifest头条目（headers）每一个应用程序模块都应该打包成OSGibundle。一个bundle本质上来说是一个具有META-INF/MANIFEST.MF文件的jar文件，MANIFEST.MF文件里包含了一系列能被OSGi
平台识别的头条目
如果bundle被启动而且至少满足如下两个条件之一，Spring extender会识别一个bundle是“具有Spring权限的”（Spring-powered），并且会为之创建一个关联的应用程序上下文：
 bundle路径包含了一个文件夹 META/spring，在该文件夹下有一个或多个XML文件。
 META/MANIFEST.MF 文件里包含了一个Spring-Context头条目另外如果可选头条目SpringExtender-Version在manifest里被声明，那么extender将只是别指定版本的extender bundle（Bundle-Version）。SpringExtender-Version头条目必须符合《OSGi Service Platform Core规范》3.2.5部分所说明的版本范围语法。
在没有Spring-Context头条目的情况下，extender将把META-INF/spring下面的所有XML文件视为有效Spring配置文件，并且所有的指令（如下所述）会具有它们的默认值。
应用程序上下文从这些文件里构造。一个推荐的做法是将上下文配置文件分成至少两个文件，习惯上分别命名为“模块名-context.xml”和“模块名-osgi-context.xml”。前者包含独立于OSGi之外的标准bean定义。后者包含输出和导入服务的bean定义。这可能（但不是必须）需要使用Spring Dynamic Modules OSGi schema作为顶级命名空间用来取代Spring的“beans”命名空间。
Spring-Context manifest头条目可以用于说明一个可变的配置文件集。所有的资源路径都被作为相对资源路径且被认为是所定义的bundle及其附属片段（fragment）的入口。只要Spring-Context头条目定义了一个配置文件位置，那么META-INF/spring下的文件都将被忽略——除非它们被Spring-Context头条目直接引用。
Spring-Context的头条值的语法如下：
Spring-Context-Value ::= context ( ',' context ) *
context ::= path ( ';' path ) * (';' directive) *
这个语法和《OSGi Service Platform Core规范》3.2.2部分里定义的OSGi Service Platform的普通头条目语法是一致的。
2、必需的Spring Framwork bundle和Spring Dynamic Modules bundle
Spring Dynamic Modules工程提供了很多现成的bundle，如果要正常使用Spring extender这些bundle必须安装到你的OSGi平台上去。
 extender bundle本身org.springframework.osgi.extender
 Spring Dynamic Modules的核心实现,org.springframework.osgi.core
 Spring Dynamic Modules I/O 支持库bundle, org.springframework.osgi.io
另外Spring Framework 提供了一些bundle 必须安装。Spring Framework2.5中 Spring jar文件中，Spring是是以有效的OSGi bundle的形式发布的，它们可以直接安装到OSGi平台中，安装的最小集为：
 spring-core.jar (bundle定义名称为org.springframework.bundle.spring.core)
 spring-context.jar (bundle定义名称为org.springframework.bundle.spring.context)
 spring-beans.jar (bundle定义名称为org.springframework.bundle.spring.beans)
spring-aop.jar (bundle定义名称为org.springframework.bundle.spring.aop)
另外如下几个支持包是必需的. 这些库的OSGi版本和 Spring Dynamic Modules的分发包在一起：
aopalliance
 backport-util (如果在JDK1.4上运行)
 cglib-nodep (如果服务代理有类，而不仅仅是接口，那么一般都需要此包)
 commons-logging API (推荐为SLF4J版本)
 logging 实现包，例如 log4j
3、Spring XML 定义支持
Spring 2.0引入了简易（http://static./spring/docs/2.5.x/reference/xsd-config.html）XML配置和可扩展（http://static./spring/docs/2.5.x/reference/extensible-xml.html）XML定义。后者使得可以创建自定义的schema——这些schema由Spring XML基础组件在classpath会里自动（在非OSGi环境里）发现。Spring-DM能在OSGi环境里意识到并支持这种操作，所以自定义的schema对于bundle是可用的，你并不需要添加额外的代码manifest声明。
如果你使用自定义schema部署一个bundle，你只需要部署包含了该shcema和命名空间解析器的库。包含在库的classpath里的所有bundle将可以在OSGi空间里使用该bundle。然而，该库的命名空间不会和其他bundle分享，也就是说它们对任何其他bundle都不可见。
通过使用Spring-DM，自定义的命名空间被显示地支持，而不需要附加工作。内嵌的命名空间不会被分享，但bundle对于其他bundle是可见的（也是可用的）。
4、导入和输出包
Import-Package和Export-Packagemanifest头条目的详情请参考OSGi 服务平台。你的bundle可能需要使用Import-Package条目来指明它所依赖的外部包。如果你的包提供对外可用的服务，你将需要使用Export-Package条目来说明之。
5、诊断问题
你所选的OSGi平台实现应该可以给你提供很多当前OSGi环境的信息
推荐的做法是部署Simple Logging Façade for Java （slf4j）的slf4j-api.jar和slf4j-log4j13.jar bundle（随工程分发的jar包已经是有效的OSGi bundle），然后你只需要简单的创建一个log4j.properties文件，放在你的bundle 的classpath根目录下。
注意Spring Dynamic Modules 在其内部使用 commons-logging API，也就是说它的logging接口是完全可插拔的。请留意FAQ和Resource网页来查看其他log4j之外的logging库的更多信息。