今天我在博客圈闲逛，偶然看到了我读过的最短的 博客文章 之一。几乎整篇文章的内容是：“每次你使用 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*……
