很多人一直在問 SpringSource Application Platform 究竟能為 Spring 應用程式做什麼，使其在 OSGi 上執行良好，這超出了 OSGi 和 Spring Dynamic Modules 開箱即用的功能。Adrian 昨天的帖子重點介紹了一些一般性問題，現在我們來看一些細節。

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

• 載入時編織
• 類路徑掃描
• 執行緒上下文類載入器管理

其餘但不太有趣的方面包括：JSP 支援、TLD 掃描、註解匹配和資源查詢。總而言之，有一些相當多的問題需要解決才能使應用程式平穩部署。

載入時編織

載入時編織是支援的一項最棘手的功能。在基本層面上，它需要掛鉤到 Equinox 的 ClassLoader，以便在 defineClass 呼叫期間可以附加和使用標準的 ClassFileTransformers。在此基礎上，許多 LTW 的用法需要訪問一個一次性的 ClassLoader，該 ClassLoader 可用於檢查型別以決定在編織期間需要做什麼，而不會影響實際的 ClassLoader。

這個基本級別的支援實際上是相當容易實現的。困難之處在於，當編織由一個 bundle 中的類驅動，但另一個 bundle 中的類需要被編織時。這在企業應用程式中很常見，其中一個 bundle 包含領域實體，另一個 bundle 包含使用 JPA EntityManager 的型別。Platform 透過確保應用程式中的所有 bundle 都可以使用適當的 ClassFileTransformers 進行編織來處理這種複雜性。

當您開始將編織傳播到其他 bundle 時，您確實需要知道何時停止。如果您只是將編織應用於所有 bundle，那麼應用程式將會相互干擾。Platform 透過顯式地限定編織範圍，使其僅應用於應用程式中的模組，從而防止這種情況發生。

LTW 的另一個問題是它會使重新整理複雜化。當一個 bundle 被重新整理時，OSGi 將重新整理所有依賴於它的 bundle。這意味著，在我上面給出的例子中，重新整理領域 bundle 會導致 EntityManager bundle 被重新整理。然而，重新整理 EntityManager **不會**重新整理領域 bundle，這意味著編織可能不同步。Platform 透過將重新整理傳播到受編織影響的其他 bundle 來處理此問題。

類路徑掃描

對於類路徑掃描，主要問題是 Equinox 不暴露標準的 jar: 和 file: 資源。Platform 在中間放置了一個介面卡，以便庫可以看到它們期望的資源協議。這有一個很好的副作用，就是使**大量**第三方庫能夠工作——這不僅僅是類路徑掃描的修復。

執行緒上下文類載入器管理

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

Platform 透過建立一個 ClassLoader 來解決這個問題，該 ClassLoader 匯入您應用程式中每個模組的所有匯出的包。然後，此 ClassLoader 作為執行緒上下文 ClassLoader 公開，使第三方庫能夠看到您應用程式中的所有匯出型別。

這只是 Platform 所解決問題的一小部分，但希望它能讓您對 Platform 對 Spring Framework 使用者意味著什麼有所瞭解。