关于headers的细节拜见OSGi标准中的3.2节。一些OSGi完结结构或许会支撑一些异乎寻常的jar包，可是这些jar包关于OSGi的格局仍是不变的。

51CTO修改引荐：OSGi入门与实践全攻略

The Spring extender recognizes a bundle as "Spring-powered" and will create an associated application context when the bundle is started if one or both of the following conditions is true:

假如满意以下两个条件，Spring extender会经过一个bundle的具有"Spring-powered"的验证，当这个bundle启动时会为其创立一个相关联的application context：

The bundle classpath contains a folder META-INF/Spring with one or more files in that folder with a '.xml' extension.

这个bundle的classpath包括一个目录META-INF/spring，这个目录中有一个或多个扩展名为'.xml'的文件。

META-INF/MANIFEST.MF contains a manifest header Spring-Context.

这个bundle中的META-INF/MANIFEST.MF文件包括一个名为Spring-Context的header。
In addition, if the optional SpringExtender-Version header is declared in the bundle manifest, then the extender will only recognize bundles where the specified version constraints are satisfied by the version of the extender bundle (Bundle-Version). The value of the SpringExtender-Version header must follow the syntax for a version range as specified in section 3.2.5 of the OSGi Service Platform Core Specification.

别的，假如bundle的manifest声明晰可选header - SpringExtender-Version，那么extender将只是认可与之版别相符的指定版别束缚的bundle（bundle的Bundle-Version）。SpringExtender-Version的值有必要遵从OSGi标准3.2.5节中指定的版别规模。

In the absence of the Spring-Context header the extender expects every ".xml" file in the META-INF/spring folder to be a valid Spring configuration file, and all directives (see below) take on their default values.

在短少Spring-Context的情况下，spring extender依然以为一切META-INF/spring中".xml"的文件都是spring的装备文件，一切的header都是默认值。

An application context is constructed from this set of files. A suggested practice is to split the application context configuration into at least two files, named by convention modulename-context.xml and modulename-OSGI-context.xml. The modulename-context.xml file contains regular bean definitions independent of any knowledge of OSGi. The modulename-osgi-context.xml file contains the bean definitions for importing and exporting OSGi services. It may (but is not required to) use the Spring Dynamic Modules OSGi schema as the top-level namespace instead of the Spring 'beans' namespace.

application context便是依据这些文件(META-INF/spring中".xml"的文件)结构的。一个引荐的做法是将application context装备文件至少分割成2个文件，习惯上命名为 [模块名－context.xml] 和[模块名-osgi-context.xml]。modulename-context.xml文件包括了不依靠与OSGi相关的bean的界说（能够理解为一般bean界说）。modulename-osgi-context.xml文件则界说那些引进或输出OSGi服务的bean。这或许需求运用Spring Dynamic Modules的OSGi schema做为***命名空间，替代spring的'bean'命名空间，但这不是有必要的。

以下是 Spring-Context的相关内容和装备，首要意思如下：

1.假如在Spring-Context指定了装备文件，那么extender将疏忽 META-INF/spring 中的装备文件，除非清晰指定。

2.能够用通配符，例如Spring-Context: osgi-*;

3.create-asynchronously=false（默认值是true） ，运用同步方法创立该bundle的application context。有一点需求留意，同步创立application context的进程是在OSGi的事情线程中进行的，它将堵塞这个线程的事情发送，直到完结application context的初始化。假如这个进程中发生了过错，那么将呈现一个FrameworkEvent.ERROR，可是bundle的状况依然仍是ACTIVE。

4.wait-for-dependencies和timeout，从字面意思就能看出来了。

5.publish-context:=false（默认值是true)，不将application context作为一个服务发布。

The Spring-Context manifest header may be used to specify an alternate set of configuration files. The resource paths are treated as relative resource paths and resolve to entries defined in the bundle and the set of attached fragments. When the Spring-Context header defines at least one configuration file location, any files in META-INF/spring are ignored unless directly referenced from the Spring-Context header.

The syntax for the Spring-Context header value is:

Spring-Context-Value ::= context ( ',' context ) * context ::= path ( ';' path ) * (';' directive) *
This syntax is consistent with the OSGi Service Platform common header syntax defined in section 3.2.3 of the OSGi Service Platform Core Specification.

For example, the manifest entry:

Spring-Context: config/account-data-context.xml, config/account-security-context.xml

will cause an application context to be instantiated using the configuration found in the files account-data-context.xml and account-security-context.xml in the bundle jar file.

A number of directives are available for use with the Spring-Context header. These directives are:

create-asynchronously (false|true): controls whether the application context is created asynchronously (the default), or synchronously.
For example:

Spring-Context: *;create-asynchronously=false
Creates an application context synchronously, using all of the "*.xml" files contained in the META-INF/spring folder.

Spring-Context: config/account-data-context.xml;create-asynchrously:=false

Creates an application context synchronously using the config/account-data-context.xml configuration file. Care must be taken when specifying synchronous context creation as the application context will be created on the OSGi event thread, blocking further event delivery until the context is fully initialized. If an error occurs during the synchronous creation of the application context then a FrameworkEvent.ERROR event is raised. The bundle will still proceed to the ACTIVE state.

wait-for-dependencies (true|false): controls whether or not application context creation should wait for any mandatory service dependencies to be satisfied before proceeding (the default), or proceed immediately without waiting if dependencies are not satisfied upon startup.
For example:

Spring-Context: config/osgi-*.xml;wait-for-dependencies:=false
Creates an application context using all the files matching "osgi-*.xml" in the config directory. Context creation will begin immediately even if dependencies are not satisfied. This essentially means that mandatory service references are treated as though they were optional - clients will be injected with a service object that may not be backed by an actual service in the registry initially. See section 4.2 for more details.

timeout (300): the time to wait (in seconds) for mandatory dependencies to be satisfied before giving up and failing application context creation. This setting is ignored if wait-for-dependencies:=false is specified. The default is 5 minutes (300 seconds).
For example:

Spring-Context: *;timeout:=60
publish-context (true|false): controls whether or not the application context object itself should be published in the OSGi service registry. The default is to publish the context.
For example:

Spring-Context: *;publish-context:=false
If there is no Spring-Context manifest entry, or no value is specified for a given directive in that entry, then the directive takes on its default value.

3.2 Required Spring Framework and Spring Dynamic Modules Bundles

The Spring Dynamic Modules project provides an number of bundle artifacts that must be installed in your OSGi platform in order for the Spring extender to function correctly:

Spring Dynamic Modules供给了许多现成的bundle，要运用Spring extender有必要将这些bundle安装到OSGi渠道中:

The extender bundle itself, org.springframework.osgi.extender
The core implementation bundle for the Spring Dynamic Modules support, org.springframework.osgi.core
The Spring Dynamic Modules i/o support library bundle, ' org.springframework.osgi.io
In addition the Spring Framework provides a number of bundles that are required to be installed. As of release 2.5 of the Spring Framework, the Spring jars included in the Spring distribution are valid OSGi bundles and can be installed directly into an OSGi platform. The minimum required set of bundles is:

别的spring还供给了许多它自己的bundle，这些bundle能够直接被安装到OSGi渠道中。要运用spring的***要求需求以下几个bundle:

spring-core.jar (bundle symbolic name org.springframework.core)
spring-context.jar (bundle symbolic name org.springframework.context)
spring-beans.jar (bundle symbolic name org.springframework.beans)
spring-aop.jar (bundle symbolic name org.springframework.aop)
In additional the following supporting library bundles are required. OSGi-ready versions of these libraries are shipped with the Spring Dynamic Modules distribution.

以下几个bundle是spring的依靠bundle，能够在Spring Dynamic Modules的分发包中找到它们:

aopalliance
backport-util (for JDK 1.4)
cglib-nodep
commons-logging (SLF4J version highly recommended)

3.3 Importing and Exporting packages

Refer to the OSGi Service Platform for details of the Import-Package and Export-Package manifest headers. Your bundle will need an Import-Package entry for every external package that the bundle depends on. If your bundle provides types that other bundles need access to, you will need Export-Package entries for every package that should be available from outside of the bundle.

这部份是关于OSGi渠道MANIFEST中Import-Package和Export-Package的细节描绘。

【修改引荐】

1. OSGi与Spring的整合
2. 实例阐明怎么集成Spring和Struts
3. 怎么在Java Web使用中获取Spring的ApplicationContext