JCA 容器

JCA 容器正在遷移

我們將持續支援 ActiveMQ Classic JCA 容器，直到 ActiveMQ Classic 3.1 版本。

在那之後，我們將遷移到 Jencks，它是 ActiveMQ Classic 程式碼庫與來自 Geronimo 和其他貢獻者的程式碼的遷移。

Jencks 在邏輯上與 ActiveMQ Classic JCA 容器完全等效，遷移到它非常簡單（主要只是 JCA 容器的類別名稱變更）- 雖然 Jencks 的優點是它支援完整的 XA 復原，並且與 Geronimo 的 TransactionManager 和 WorkManager 良好運作。

因此，我們建議您盡可能遷移到 Jencks；例如 Lingo 和 ServiceMix 等專案已經完成遷移，而且遷移過程很輕鬆。

我們有一個輕量級、易於嵌入的基於 Spring 的 JCA 容器，讓我們可以在任何 Java 應用程式中提供類似 MDB 的功能，而無需完整的 EJB 容器。

這使我們能夠使用依賴注入來支援訊息驅動的 POJO，以進行高效的 JMS 消費，並使用輕量級容器而不是依賴 EJB 來池化 POJO。

JCA 容器還使在執行階段以程式設計方式建立新的訊息驅動 POJO 變得容易，而不是僅依賴 EJB 的固定部署時選項。

範例

這是一個範例，展示了 Spring XML 如何在特定的範例中，於主題的入站 JMS 訂閱上部署一個 POJO (EchoBean)。

首先，我們可以根據需要建立多個 JCAContainer 實例；目前，我們為每個 JCA 資源轉接器（即 JMS 提供者）建立一個實例。JCAContainer 也使用 WorkManager，這是 JCA 術語中的一組執行緒池。我們可以在 JCAContainer 實例之間共享 WorkManager，或為每個 JCAContainer 建立一個。

一旦我們有了 JCAContainer，我們可以透過 addConnector 工廠方法向其新增多個 JCAConnector 實例，每個實例代表一個 JMS 訂閱，並提供一個 POJO 池來處理訊息。訂閱詳細資訊由 activationSpec 屬性指定，該屬性是一個通常依賴於 JMS 提供者的 Bean；這允許提供者新增新的擴充功能，同時讓您的應用程式程式碼保持純 JMS。

請注意，正規的 Spring 池化機制，即 targetSource 屬性，用於池化實際的 POJO，並且 Spring 使用依賴注入來建構 POJO 的實例。

注意：如果 POJO 不是執行緒安全的，則必須將 singleton 旗標設定為 false。

需求

若要使用 JCA 容器，您只需要將以下 JAR 檔案加入類別路徑即可

如果您使用 ActiveMQ Classic 作為您的 JMS 提供者，則需要 ActiveMQ Classic JAR 檔案 - 如果不是，則需要您提供者的 JAR 檔案
activemq-container.jar
spring.jar
J2EE.jar（用於 JCA API）。如果您在 Tomcat 中，它不喜歡類別路徑中的 j2ee.jar，因此請使用 Geronimo 中的個別 JAR 檔案 - 例如，用於 JCA API 的 geronimo-spec-j2ee-connector-*.jar
commons-collections.jar
commons-pool.jar
aopalliance.jar（這是 Spring 使用 TargetSource 引入的暫時依賴，我們應該能夠稍後移除此依賴）。

`注意** activemq-container.jar 中的類別和資源不包含在 activemq.jar 中

若要使用 JCA 容器，請使用 2.x 程式碼發行版。1.x 程式碼分支發現並修復了一些問題。

注意事項

預設情況下，ActiveMQ Classic 資源轉接器將嘗試連線到遠端 Broker（即 tcp://127.0.0.1:61616）。如果您想透過 XML 設定如何配置 Broker，請嘗試 brokerXmlConfig 屬性。

注意：在 AMQ 3.x 中，ActiveMQ Classic 資源轉接器的預設行為將建立一個嵌入式 Broker