祝賀 WebLogic 團隊釋出了 WebLogic 10 的預覽版，該版本通過了 Java EE 5 CTS。 很高興看到 BEA 在 J2EE 1.4 出現偏差後，恢復了快速行動的傳統。

這對 Spring 社群來說是個有趣的訊息，因為 WebLogic 10 在內部使用了Pitchfork。 Pitchfork 專案是由 Interface21 領導並與 BEA 合作開發的開源專案，它在 Spring 之上實現了 EJB 3.0 攔截和 JSR-250 注入。 它在 WebLogic 10 EJB 容器和伺服器的其他部分中使用，以滿足新的規範要求，但不與 WebLogic 繫結。 Pitchfork 可以獨立使用（儘管這不是其主要目標），也可以被其他應用伺服器採用。

順便說一句，Pitchfork 專案不應與德國樂隊Project Pitchfork混淆。 最新訊息：我剛剛發現他們有一首歌叫做It's Spring。 雖然我不是他們的粉絲...

使用 Pitchfork 意味著從 WebLogic 10 的執行時角度來看，每個 EJB 3.0 會話或訊息 bean 也是一個 Spring bean。 BEA 做出此選擇的動機是實現快速上市，並在儘可能的情況下基於經過驗證的程式碼來實現新規範功能。 事實上，Spring 已經做了很多他們需要做的事情，這有助於他們實現積極的時間表。 它還有助於確保安全的升級路徑。 許多新功能由 Pitchfork 在經過驗證的 Spring 程式碼之上提供； 絕大多數經過驗證的現有 WebLogic EJB 程式碼庫保持不變。 當然，採用這種方法突顯了 BEA 對 Spring 質量的信任。

從長遠來看，在 WebLogic 上執行 Spring 的使用者應該會受益於 Spring 在表面之下的使用，允許伺服器在深層管理 Spring 元件（伺服器已經有效地“原生”理解它們），並使 Spring 元件模型能夠用於補充 Java EE。 EJB 負責人 Patrick Linskey 最近暗示了其中的一些功能

這種架構還為我們提供了一些機會，可以在更整合的層面上向 WebLogic Server 開發人員公開 Spring 元件... [例如] ... 在 WebLogic Server 叢集中部署 Spring bean； Spring 會話複製（利用 WebLogic HTTP 會話複製）； WebLogic 安全性與 Spring bean 的整合； 基於 WebLogic 的 Spring bean 叢集遠端處理； 以及在 WebLogic Server 管理控制檯中管理 Spring bean。 此外，我們在內部為一些引人注目的、面向外部的 Spring 整合功能奠定了基礎，但我們尚未在 WebLogic Server 10 中公開這些功能。

在之前的預覽中，可以訪問伺服器內部的 Spring 並實際使用它進行程式設計。 Spring IDE 團隊充滿活力的 Christian Dupuis 在第一個預覽版釋出時發表了部落格，展示了每個 EJB 3.0 會話或訊息 bean 也是一個 Spring bean，並且可以透過提供與 EJB 同名的 Spring bean 定義，將更強大的 Spring 注入和真正的 AOP 應用於這些元件，這是一種簡單而優雅的方法。 我不確定這種機制在當前的預覽版中是否有效，並且還沒有時間進行檢查； 我知道 BEA 的目標是首先發佈一個符合規範的伺服器，然後研究如何最好地打包和記錄增值擴充套件。

很高興與 WebLogic EJB 團隊合作開發 Pitchfork 及其在 WebLogic 中的使用——特別是 Michael Chen 和 Patrick Linskey。 不可避免地，與 Patrick 的一些工作是在啤酒中進行的。

顯然，我對 Spring 角度特別興奮（尤其是我和 Costin Leau 參與其中），但 WebLogic 10 中當然還有很多其他重要的東西：特別是，將 Kodo/OpenJPA 作為 JPA 永續性提供程式合併。 該產品的核心是 Apache License 開源。 很高興看到繼續強調 QOS 功能，而不僅僅是 API 追逐：例如，自動 JMS 故障轉移。 特別是大型企業客戶通常更關心運營和正常執行時間，而不是規範級別。

過濾類載入器聽起來特別受歡迎（如果來得晚的話）。 複雜應用程式中的 J2EE 類載入傳統上是人間地獄——痛苦且真正阻礙了應用程式的移植，即使它們按照標準進行編碼並使用可移植框架也是如此。 隨著伺服器（包括 WebLogic 和 WebSphere）越來越多地在內部使用開源，衝突變得越來越普遍，需要進行 hack 修復。 （就像 ANTRL 與 Hibernate 3 和 WebLogic 8.1 的衝突一樣，可以透過使 WAR 中的庫優先於伺服器中的庫來解決。） 看來 WebLogic 10 將在此處提供一個可靠的解決方案，該解決方案使特定應用程式能夠以更靈活的方式過濾掉伺服器依賴的類。