很多人一直在問，SpringSource Application Platform 到底為 Spring 應用程式做了哪些事情，使其在 OSGi 下能夠順利執行，而這是僅使用 OSGi 和 Spring Dynamic Modules 無法實現的。Adrian 昨天的文章強調了一些普遍性的問題，現在讓我們來看看其中的一些細節。

在 OSGi 上執行 Spring 應用程式的三個最具挑戰性的方面是

• 載入期織入 (Load-time weaving)
• 類別路徑掃描 (Classpath scanning)
• 執行緒內容類別載入器管理 (Thread context classloader management)

其餘的，但較不重要的問題包括：JSP 支援、TLD 掃描、註解匹配和資源查找。總體而言，需要解決一系列相當多的問題，才能使應用程式順利部署。

載入期織入 (Load-time weaving)

載入期織入 (Load-time weaving) 是以穩健的方式支援中最有問題的功能之一。在基本層面上，它需要連接到 Equinox ClassLoader，以便可以附加標準 ClassFileTransformers，並在 defineClass 呼叫期間使用。最重要的是，許多 LTW 的使用需要訪問一個拋棄式的 ClassLoader，可以用於檢查類型以決定在織入期間需要做什麼，而不會影響實際的 ClassLoader。

實際上，實現這種基本層級的支援相當簡單。困難之處在於，當織入由一個 bundle 中的類驅動，但另一個 bundle 中的類需要被織入時。這在企業應用程式中非常常見，其中一個 bundle 包含 domain entities，另一個包含使用 JPA EntityManager 的類型。該平台通過確保應用程式中的所有 bundles 都可以使用適當的 ClassFileTransformers 進行織入來處理這種複雜性。

當您開始將織入傳播到其他 bundles 時，您真的需要知道何時停止。如果您只是簡單地將織入應用於所有 bundles，那麼應用程式將會互相干擾。該平台通過顯式地劃定織入的範圍，使其僅應用於應用程式中的模組，從而避免了這種情況的發生。

LTW 的另一個問題是它使刷新變得複雜。當一個 bundle 被刷新時，OSGi 將會刷新所有依賴於它的 bundles。這意味著，在我上面給出的例子中，刷新 domain bundle 將會導致 EntityManager bundle 被刷新。但是，刷新 EntityManager **不會** 刷新 domain bundle，這意味著織入可能不同步。該平台通過將刷新傳播到受織入影響的其他 bundles 來處理此問題。

類別路徑掃描 (Classpath scanning)

對於類別路徑掃描 (classpath scanning)，主要問題是 Equinox 不會公開標準的 jar: 和 file: 資源。該平台在中間放置了一個适配器，以便程式庫看到它們期望的資源協議。這有一個很好的副作用，那就是使**很多**第三方程式庫能夠正常工作 - 它不僅僅是類別路徑掃描的修復。

執行緒內容類別載入器管理 (Thread context classloader management)

許多第三方程式庫使用執行緒內容 ClassLoader 來訪問應用程式類型和資源。OSGi 中的每個 bundle 都有自己的 ClassLoader，因此，任何時候只能將一個 bundle 作為執行緒內容 ClassLoader 公開。這意味著，如果一個第三方程式庫需要查看分佈在多個 bundles 中的類型，它將無法按預期工作。

該平台通過創建一個 ClassLoader 來修復此問題，該 ClassLoader 導入應用程式中每個模組的所有導出 package。然後將此 ClassLoader 作為執行緒內容 ClassLoader 公開，使第三方程式庫能夠查看應用程式中的所有導出類型。

這只是該平台解決的眾多問題中的一小部分，但希望它可以讓您了解該平台對 Spring Framework 使用者的意義。