今天我在部落格圈閒逛，偶然看到了我讀過的最短的 部落格文章 之一。幾乎整篇文章的內容是：“每次你使用 Acegi，就會有一隻小精靈死去。可悲的是，確實沒有什麼更好的東西可以用……”
透過我們的 社群論壇、開發者 郵件列表、JIRA、使用者 大會 BOFs、培訓、支援、諮詢 和 團隊部落格，我們收到了大量的社群反饋。毫無疑問，許多人一直在尋求改進 Spring Security（以前稱為 Acegi）的配置格式，並且我們已經投入了大量時間來實現這一目標。
在下週的 Spring Experience 大會上，我將進行 演講，屆時將介紹 Spring Security 2.0.0 M1 版本，它提供了極大簡化的配置。現在，您可以將 Spring Security 新增到您的……
自 Spring 2.0 引入 Spring 動態語言支援以來，它一直是 Groovy 的一個有吸引力的整合點，而 Groovy 為定義領域特定語言 (DSL) 提供了豐富的環境。但是，Spring 參考手冊中 Groovy 整合的示例範圍有限，並未展示 Spring 中針對 DSL 整合的功能。在本文中，我將展示如何使用這些功能，並以 Grails 發行版中的 Groovy DSL 向現有 ApplicationContext 新增 Bean 定義為例。
Spring 動態語言整合的一些基本功能在 XML 的“lang”名稱空間中公開。最直接的做法是將 Spring 元件定義為 Groovy bean，可以將其放在單獨的檔案中，也可以直接嵌入在 XML 中。此功能在 Spring 參考指南中有所涵蓋（http://static.springframework.org/spring/docs/2.5.x/reference/index.html……
應 廣大使用者 的要求，Spring Framework Maven 構件現在已上傳到 Spring Snapshot Maven 倉庫。您可以在我 之前的博文 中找到有關所有 Spring Portfolio Maven 倉庫的詳細資訊，但我將在此處重新發布 Spring snapshot 倉庫的詳細資訊。
Spring Snapshot Maven 倉庫位於 http://s3.amazonaws.com/maven.springframework.org/snapshot。使用此倉庫需要在您的 POM 檔案中的 <repositories/> 元素中新增一個條目。它看起來應如下所示：
<repository>
<id>spring-snapshot</id>
<name>Spring Portfolio Snapshot…我們正在更改公司名稱。本週，Interface21 將更名為 SpringSource。
在我們公司發展壯大的過程中，Interface21 以卓越的產品、思想領導力、優秀的團隊、專業的服務以及頂級的支援而聞名。隨著我們繼續提供所有這些，我們相信更改公司名稱將有助於我們的公司將它們帶給更廣泛的受眾。
當我於 2004 年創立 Interface21 時，我必須選擇一個名字。我相信 Spring 是企業 Java 的未來，“Interface21”反映了這種感受——21 世紀的框架。現在我們……
Spring Web Flow 2.0 M2 已 釋出。我對這個版本特別興奮，因為它為我們社群的未來實現宏大願景奠定了基礎。在這篇文章中，我將解釋這個願景是什麼，以及這個基礎將具體實現什麼。我還會詳細介紹 Web Flow 2.0 的架構，並將其與 1.0 版本進行比較。
* 更新：在 2007 年 Spring Experience 大會之後，在收到 Spring 社群的大量反饋後，上述願景已於 08 年 1 月 11 日更新。根據這些反饋，Spring Web Flow 2……
Spring 2.5 引入了一種編寫註解式 Web MVC 控制器的方法，我們對此的部落格介紹還不多……我將藉此機會概述一下 Spring MVC 目前的真正意義。
Spring MVC 本質上是一個請求分發框架，提供 Servlet API 和 Portlet API 變體。它在其託管環境（Servlet 或 Portlet）內緊密執行。可以將 Spring MVC 視為在 Servlet/Portlet 容器之上提供了基礎功能和便利性：例如，靈活的請求對映，控制器之間的分離……
昨晚，我參加了一個新英格蘭 Java 使用者組 (NEJUG) 的會議，Reza Rahman 在會上做了關於 EJB 3 和 Spring 的“比較分析”的演講。Reza 是 EJB 3 in Action 的作者之一。我很高興認識 Reza，並尊重他敢於討論可能被視為有爭議的話題。我也很感激他確實嘗試討論了 EJB 3 和 Spring 的優缺點。儘管如此，我還是覺得有必要澄清他關於 Spring 的一些說法不夠準確，這些說法導致我（和其他與會者）認為這次演講是出於對 EJB 3 的偏見。公平地說，與固定的規範版本不同，Spring 正在不斷發展，我在這裡指出的其中一些是新功能。另一方面，其中一些是 Spring 2.0 的功能，已經可用一年多了。我個人認為，“比較分析”必須考慮到所比較產品最新穩定版本的最新功能集。我想不言而喻，我也可能有點偏見，但我的動機是提供一個完全客觀的回應，以便這次演講能夠被修改，以反映更“同類比較”。我將簡要回應這次演講中的 10 個“主題”。
會上提到 Spring 開始支援更多註解，但“還需要一段時間”。然而，Spring 2.0 版本提供了完整的 JPA 整合，使用 @PersistenceContext 註解來注入 EntityManager，並提供了註解驅動的事務管理，使用 Spring 的 @Transactional 註解（支援與 @Stateless EJB 相同的語義，預設傳播級別為 REQUIRED）。我特別感到失望的是，比較中沒有在雙方都包含 JPA（見下文第 3 點）。Spring 2.0 還引入了完整的基於註解的 AspectJ 支援（@Aspect、@Before、@After、@Around）以及“構造型”註解的概念。例如，@Repository 註解為直接使用 JPA 或 Hibernate API 的資料訪問程式碼（無需 Spring 的模板）提供了非侵入式的異常翻譯。Spring 早在 1.2 版本就提供了註解支援，例如 @ManagedResource，用於透明地將任何 Spring 管理的物件匯出為 JMX MBean。
對我來說，這個問題排在第一位的主要原因是“這需要他們一段時間”的評論。作為 Spring 2.5 註解驅動配置支援的主要開發者之一，我必須說 Spring 元模型非常靈活，因此我們能夠比預期的更快地提供一個全面的基於註解的模型。事實上，Spring 2.5 支援 JSR-250 註解：@Resource、@PostConstruct 和 @PreDestroy，以及 @WebServiceRef 和 @EJB。特別有趣的是 @Resource，因為它是 EJB 3 中用於依賴注入的主要註解。在 Spring 中，@Resource 註解不僅支援 JNDI 查詢（如 EJB 3），還支援注入**任何 Spring 管理的物件**。這有效地結合了這次演講中提到的主要 Spring 優勢（Spring 支援任何型別的物件 DI）和主要 EJB 3 優勢（使用註解而不是 XML）。Spring 2.5 還引入了一個更細粒度的基於 @Autowired 和（可擴充套件的）@Qualifier 註解的註解驅動的依賴注入模型。Spring 2.5 還擴充套件了“刻板印象”註解，包括 @Service 和 @Controller。每個刻板印象註解都透過將其作為元註解來擴充套件通用的 @Component 註解。透過應用相同的技術，@Component 註解為使用者定義的刻板印象提供了擴充套件點。Spring 甚至可以自動檢測這些註解的元件，作為 XML 配置的替代方案。例如，這個片段摘自 2.5 版的 PetClinic 示例應用程式。
<context:component-scan base-package="org.springframework.samples.petclinic.web" />
由於 Web 控制器使用了註解驅動的依賴注入和用於請求對映的註解，因此不需要額外的 XML。我之所以指出這一點，是因為演講特別強調了 Web 層的配置的冗長。
@Controller
public class ClinicController {
private final Clinic clinic;
@Autowired
public ClinicController(Clinic clinic) {
this.clinic = clinic;
}
...
有關 Spring 註解支援的最新介紹，請參閱：The Server Side 上的 Spring 2.5 入門教程，或最新版本的 Spring 參考手冊 - 特別是基於註解的配置部分。此外，請繼續關注本部落格和 Spring Framework 主頁，瞭解即將釋出的關於 2.5 版的文章和部落格。
這實際上被 presenters 作為一個 Spring 的優勢來介紹，但強調了配置的開銷。事實是，任何認真對待測試和敏捷開發的專案的都將需要支援“多種部署環境”。換句話說，這個特定主題經常被曲解，好像它只適用於多種*生產*環境。實際上，在每個開發和測試周期中都部署到應用伺服器會是敏捷性的一個重大障礙。通常，Spring 使用者會模組化其配置，以便“基礎設施”配置（例如 DataSource、TransactionManager、JMS ConnectionFactory）是獨立的，並且動態屬性被外部化。由於 Spring 支援根據外部化屬性替換 '${placeholders}'，因此包含不同的屬性檔案通常會變成一個透明的問題。
我必須承認，這最讓我惱火。在比較幻燈片中，EJB 3 示例顯示了使用*entityManager*進行資料訪問的 JPA，並且*entityManager*例項是透過 @PersistenceContext 註解提供的。另一方面，Spring 示例使用了 Hibernate，並顯示了 Hibernate SessionFactory 的 setter 注入。在我看來，這違反了真正“比較分析”的第一條規則：使用比較雙方最相似的功能。在這種特定情況下，Spring 確實支援直接使用 JPA API（即 JpaTemplate 完全是可選的；“entityManager”的直接使用仍然參與 Spring 事務等），並且 Spring 也識別 @PersistenceContext 註解。自從 Spring 2.0 以來（最終釋出已有一年多），一直提供此支援，因此我不明白為什麼比較不也使用 Spring 端的 JPA。比較的其他部分顯然基於 Spring 2.0，這給人一種選擇性過時和暴露偏見的印象。如果這個特定的例子被修改為“同類比較”，它將破壞一個主要的總體主題：Spring 需要更多配置，而 EJB 3 依賴於標準註解。
現在，儘管我認為在 Spring 端使用 Hibernate 而不是 JPA 扭曲了比較，但它同時也揭示了 Spring 的一個優勢。如果您確實想直接使用 Hibernate API 而不是依賴 JPA API，Spring 支援這一點，並且它在 Spring 事務管理和異常翻譯方面以一致的方式實現。這就有機會使用超越 JPA 限制的 Hibernate 功能，例如 Hibernate 的“criteria”查詢 API。同樣，如果您想新增一些直接的 JDBC 進行資料訪問，而 ORM 是過度的話，Spring 也支援這一點——即使是在與 Hibernate 或 JPA 資料訪問相同的事務中呼叫。
一個具體的例子是事務管理器的定義。有人說您必須瞭解容器供應商級別的知識才能配置 Spring 整合。這是不正確的。例如，以下 bean 定義不包含任何特定於容器的資訊，但 Spring 將自動檢測所有 Java EE 應用伺服器中的事務管理器。
<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"/>
如果您確實想利用特定於容器的功能，例如每個事務的隔離級別，那麼 Spring 也提供了一些專門的實現：*WebLogicJtaTransactionManager*、*WebSphereUowTransactionManager* 和 *OC4JJtaTransactionManager*。切換這些實現之間只需更改這一個定義。
除此之外，Spring 的配置幻燈片不必要地冗長。我擔心這也可能是出於強調 EJB 與 Spring 不同，依賴於智慧預設值的目的。例如，幻燈片顯示了
<tx:annotation-driven transaction-manager="transactionManager"/>
實際上，如果 Spring 上下文中只定義了一個 'transactionManager'，那麼 'annotation-driven' 元素上就不需要顯式提供該屬性。該屬性僅用於啟用在一個應用程式中*如果需要*使用多個事務管理器。這些“自動檢測”和“智慧預設”技術貫穿於 Spring，例如訊息偵聽器的 JMS 'connectionFactory'（在下面的示例 #6 中有體現）以及現有 MBean 伺服器或 RMI 登錄檔的自動定位。
從積極的方面來看，它實際上被提到是 Spring 允許“本地”事務管理的一個優勢。雖然 EJB 需要 JTA 進行事務管理，但許多應用程式不需要跨兩階段提交能力資源進行分散式事務。在這種情況下，Spring 允許使用更簡單、開銷更低的事務管理器：DataSourceTransactionManager（用於 JDBC）、HibernateTransactionManager 或 JpaTransactionManager。如果目標是準確描述優缺點，我本應聽到更多關於 Spring 這一特定優勢的細節。例如，這對於在容器外進行測試或在 Eclipse 或 IDEA 等輕量級 IDE 環境中開發是一個巨大的好處。
此外，如果您確實需要 JTA 進行分散式事務，但又想在 Tomcat 或 Jetty 等輕量級容器中執行，Spring 可以輕鬆支援 Atomikos 和 JOTM 等獨立的 JTA 提供商。當然，Spring 的事務管理器設定需要配置一個*單個* bean 定義，但這確實是一次性成本——但絕對值得。
無狀態服務層的優點作為最佳實踐已經相當確立，Spring 也採納了這一點。然而，Spring 確實提供了單例以外的範圍。Spring 的“prototype”範圍為每次注入或查詢提供了一個獨立的例項，Spring 2.0 引入了 Web 範圍：“request”和“session”。範圍機制本身甚至可以擴充套件；可以定義自定義範圍並將其對映到對話的概念。Spring 還支援使用 CommonsPoolTargetSource 進行簡單的物件池，但物件池很少是狀態管理的最佳解決方案。
更重要的是，Spring 透過 Spring Web Flow 為 Web 應用程式提供了非常健壯、高度可配置的狀態管理。在那裡，對話狀態是透明管理的，這與本次演講中聲稱的開發人員必須直接與 HTTP Session 互動來管理 Spring 應用程式狀態的說法相反。此外，儲存庫配置是可插拔的，因此可以使用各種策略來物理儲存狀態（session、client、後端快取等）。最後，Spring Web Flow 的最新發展包括對擴充套件持久化上下文的支援以及對 JSF 的完全整合支援。
Spring 2.5 提供了一個新的 'jms' 名稱空間，以大大簡化訊息偵聽器的配置。請注意，沒有為每個偵聽器配置單獨的容器。多個偵聽器共享配置，並且廣泛使用了智慧預設值。
<jms:listener-container>
<jms:listener destination="queue.confirm" ref="logger" method="log"/>
<jms:listener destination="queue.order…我們最近舉辦了一個關於“Spring in Production”主題的網路研討會。我當時承諾將在我們的網站上提供網路研討會的錄音和配套幻燈片。不幸的是，為我們製作網路研討會的工程師忘記設定“record”標誌，所以我需要為您重新錄製課程 :(。我現在正在旅行，但我會盡快嘗試完成並提供。
好訊息是，您在此期間無需錯過。我寫了一份關於“Spring in Production”主題的 白皮書，其中涵蓋了網路研討會的內容以及更多……
幾位使用者詢問我們是否致力於 Spring Java 配置，以及它與 Spring 2.5 中引入的 註解配置選項 的關係。答案是肯定的，我們致力於 Java 配置；這兩種方法並非互斥。
這兩種配置方法截然不同：Spring Framework 配置中的 @Autowired 註解使用業務物件中的註解來配置元件，而 Spring Java 配置則採用一種獨特的方法，將註解外部化到專用的配置類中。這兩種方法都不是唯一正確的……
正如一些使用者可能已經注意到的，Spring 2.5 RC1 已於週一釋出，等待您進行測試！Spring 2.5 在許多方面完成了*Spring 2.0 的使命*：為 Java 1.4 和 Java 5 提供最靈活、最*全面的配置模型*。Spring 2.5 專注於對 Java 5 提供特別全面的支援，引入了各種進一步的註解選項。我想借此機會指出本次釋出背後的統一主題。
Spring 2.5 允許*便捷的外部化配置*，同時保持儘可能簡潔。這建立在 Spring 2.0 對 XML 模式名稱空間的支援之上，Spring 2.5 引入了*新的“context”和“jms”配置名稱空間*。後者是 Spring 配置名稱空間可以提供的增值的絕佳示例——如果您正在使用 Spring 2.0 風格的訊息驅動物件，絕對值得采用！此外，Spring 還允許*以程式設計方式引導，完全無需 XML*……
