很多人都在問，SpringSource Application Platform 究竟為 Spring 應用做了什麼，使其在 OSGi 下執行良好，除了 OSGi 和 Spring Dynamic Modules 可以直接提供的功能之外。Adrian 昨天的文章重點介紹了一些常見問題，現在讓我們看看其中的一些細節。

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

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

其餘但不太重要的問題包括：JSP 支援、TLD 掃描、註解匹配和資源查詢。總而言之，需要解決大量問題才能使應用程式順利部署。

載入時織入

載入時織入是最難支援的功能之一。 在基本層面上，它需要連線到 Equinox ClassLoader，以便可以在 defineClass 呼叫期間附加和使用標準 ClassFileTransformers。 除此之外，LTW 的許多用途都需要訪問一次性的 ClassLoader，該類載入器可用於檢查型別，以確定在不影響實際 ClassLoader 的情況下在織入期間需要發生的事情。

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

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

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

類路徑掃描

對於類路徑掃描，主要問題是 Equinox 不公開標準 jar: 和 file: 資源。 該平臺在中間放置一個介面卡，以便庫看到它們期望的資源協議。 這有一個很好的副作用，可以使很多第三方庫工作 - 它不僅僅是類路徑掃描的修復程式。

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

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

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

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