8.1.Bundle格式和Manifest頭

每一個應用模組都應打包成一個OSGi的bundle。bundle本質上是包含META-INF/MANIFEST.MF檔案的jar檔案，MANIFEST.MF檔案包含了OSGi服務平臺能夠識別的一系列頭資訊。參見OSGi服務平臺核心規範第3.2節瞭解細節。一些OSGi實現可能支援零散的jar檔案，但是格式是相同的。

Spring extender能識別基於Spring的bundle，當這個bundle啟動的時候，Spring extender將會建立與這個bundle相關的應用上下文。下面的一個條件為真：

1. bundle的路徑包含一個資料夾META-INF/spring
   ，這個資料夾下有一個或多個xml檔案。
2. META-INF/MANIFEST.MF包含一個清單頭Spring-Context。

另外，如果在bundle的manifest中聲明瞭可選的SpringExtender-Version頭，那麼extender只會識別滿足版本約束(Bundle-Version)的bundle。SpringExtender-Version頭的只必須遵循OSGi服務平臺核心規範第3.2.5節指定的版本範圍。

如果缺少Spring-Context頭，那麼extender期望META-INF/spring資料夾下的每一個".xml"檔案都是合法的Spring配置檔案，所有的指令都取預設值，如下所示：

Spring-Contextmanifest頭資訊用於指定可選的配置檔案。資源路徑是相對的資源路徑，解析bundle

Spring-Context頭資訊的語法是：

Spring-Context-Value ::= context ( ',' context ) *

context ::= path ( ';' path ) * (';' directive) *

這個語法與OSGi服務平臺公共頭語義定義是一致的（OSGi服務平臺核心規範第3.2.3節）。

例如，manifest條目：

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

表明要用bundle jar檔案中的account-data-context.xml和account-security-context.xml兩個檔案中的配置例項化應用上下文。

許多指令都用於Spring-Context頭。這些指令包括：

1. create-asynchronously(false|true):控制是否非同步（預設值）或者同步建立應用上下文。例如

Spring-Context: *;create-asynchronously:=false

同步建立應用上下文，用META-INF/spring檔案下的所有xml檔案。

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

用config/account-data-context.xml配置檔案同步建立應用上下文。 注意，當同保護建立應用上下文時，建立應用上下文時在OSGi事件執行緒中，它會阻塞後面的事件傳遞，直到這個上下文完全初始化完成。如果在同步建立應用上下文時發生錯誤，那麼就產生FrameworkEvent.ERROR事件。這個bundle仍然會變為Active狀態。

2. wait-for-dependencies(true|false):控制應用上下文的建立是否應該等待強制服務依賴滿足，或者不等待服務依賴啟動。例如:

Spring-Context: config/osgi-*.xml;wait-for-dependencies:=false

用配置目錄下所有匹配"osgi-*.xml"的檔案建立應用上下文。上下文建立立即開始，即使依賴不滿足。這從本質上意味著強制的服務引用被作為可選項對待-客戶端注入的服務物件可能不是登錄檔中實際的服務。參見瞭解更多細節。

3. timeout(300):在放棄和應用上下文建立失敗之前，等待服務依賴滿足的時間。這個設定會被忽略，如果指定了wait-for-dependencies:=false。預設超時時間為5分鐘（300秒）。

例如:

Spring-Context: *;timeout:=60

建立應用上下文時，等待強制依賴的時間為1分鐘（60秒）。

4. publish-context(true|false):控制應用上下文物件自己是否應該釋出到OSGi服務登錄檔中。預設是會發布這個上下文的。

例如:

Spring-Context: *;publish-context:=false

如果沒有Spring-Contextmanifest條目，或者條目中沒有指定值，那麼這個指令就取預設值。

8.2.Blueprint Manifest配置比較

下面的表格總結了Eclipse Gemini Blueprint/Spring DM和Blueprint Container之間的manifest配置選項差異：

表8.1. 配置設定區別

下面的manifest中的配置是等價的：

8.3.Extender配置選項

除了特定bundle的配置，Gemini Blueprint和Spring DM允許配置核心extender通用行為 。當把Spring DM嵌入到管理環境或者當期望bundle範圍的功能，這就有用了。為了允許擴充套件配置，extender依賴來覆蓋預設值。extender查詢位於bundle空間的META-INF/spring/extender資料夾下的所有xml檔案，並聚合到應用上下文中(型別為OsgiBundleXmlApplicationContext)，這是內部用於配置。為了覆蓋extender的預設設定，從下表中查詢合適的bean名字，以合適的方式定義它，然而將它作為spring-osgi-extender.jar的附屬fragments，使用：

Fragment-Host: org.eclipse.gemini.blueprint.extender

下面的bean當前可以被extender識別：

表8.2. Extender配置選項

從extenderPropertiesbean，下面的屬性被識別：

另外，在Eclipse Gemini Blueprint中，引入了新的系統屬性來控制提供名稱空間的bundle是否被認為應該處於RESOLVED (預設)或STARTED狀態。前一種狀態允許一旦安裝到OSGi框架的bundle的依賴解析了，就可以獲得該名稱空間-它的優勢是名稱空間儘可能快的變為可用，但是缺點是，要移除名稱空間，就需要移除源bundle。後面的狀態只有當源bundle實際啟動時，才會強制考慮名稱空間，要移除名稱空間，只需要簡單的停止它自己的bundle即可。然而，bundle的啟動順序會影響名稱空間的可用性-提供名稱空間的bundle需要先啟動，使用這些名稱空間的bundle後啟動-依賴於應用，這樣的依賴圖可能導致難以捉摸的問題（在執行時）。因此，如果定義了系統屬性org.eclipse.gemini.blueprint.ns.bundles.started，並設定為true，那麼只有started狀態的bundle的名稱空間才被考慮，如果設定false，那麼resolved狀態的bundle會被使用。

表8.3. 可用的extenderProperties