一些用户询问我们是否致力于Spring Java 配置，以及它与 Spring 2.5 中引入的注解配置选项的关系。答案是肯定的，我们致力于 Java Config；并且这两种方法不是互斥的。

这两种配置方法截然不同：Spring Framework 中的 @Autowired 注解使用业务对象中的注解来配置组件，而 Spring Java Config 采用了一种独特的方法，将注解外部化到专用的配置类中。这两种方法都没有绝对的对错，并且在不同的情况下都很有吸引力。甚至没有理由不能在同一个应用程序中使用这两种方法。

如果您认为 Spring = XML，那么是时候重新思考了。（无论如何，这从来都不是完全准确的，因为 Spring 核心容器一直使用自己的 Java 元数据，并且不了解 XML 或任何其他表示形式。）

这引出了一个重要的哲学原则：我们在 Spring 中的使命是为企业 Java 提供最佳的组件模型，为满足复杂需求设置灵活性标准，并为现实世界的问题提供全面的解决方案。我们不相信有一种适合所有配置的模型，并且我们相信在我们强大的、可扩展的模型中适应选择。无论您选择如何定义您的 Spring 管理的对象，它们都有资格获得相同丰富的企业服务、无与伦比的第三方集成、真正的 AOP、许多扩展点等。

因此，Spring 2.5 的 @Component 和 @Autowired 注解，它们使容器能够自动检测 Spring 管理的对象，可以与 Java Configuration、XML 和其他配置选项愉快地共存。

这让我想起来：本周晚些时候，我将在旧金山的 QCon 上谈论配置 Spring 容器的方法，并且获得反馈应该会很有趣。我会看看是否可以将幻灯片发布到这里或 SpringFramework.org 上。

由于 Costin 致力于用于 OSGi 的 Spring 动态模块，Spring Java Configuration 停滞了一段时间，但现在它已步入正轨。在过去的几天里，我在这方面做了很多工作：将其更新到 Spring 2.5；删除未使用的代码；并添加了一个经常被要求的新功能——配置值的外部化，以及 bean。

虽然 M2 在 2.5RC1 上运行良好（考虑到 JavaConfig 对 Spring IoC 的使用深度，这充分说明了 2.5 的向后兼容性），但它包含了自己的注解扫描代码（Spring Framework 采用了该代码并继续推进），因此迁移到更高版本的 Spring 是有意义的。

新的配置属性外部化功能采用了 JIRA 中使用抽象方法的建议（感谢 Guillaume Duchesneau）。

这些方法使用新的 @ExternalValue 注解进行注释，如下所示

@Bean
public Person john() {
	Person john= new Person();
	john.setName(getName());
	john.setAge(methodWithArbitraryNameReturningAge());		
	john.setBusy(busy());
	return john;
}
	
    // Property name defaults to method name.
    // In the case of a getter method, it's the property name--
    // "name" in this case
@ExternalValue
public abstract String getName();
	

    // Property name is taken from annotation value
@ExternalValue("age")                  
public abstract int methodWithArbitraryNameReturningAge();
	
@ExternalValue
protected abstract boolean busy();
	

}

Spring Java Config 对这些类进行子类化，以实现这些方法，从而在运行时返回外部化属性。（无论如何，它都会对配置类进行子类化，因为其他原因，例如缓存单例 bean 方法返回值。）这些方法可以是 public 或 protected。

配置类上的 @ResourceBundles 注解标识一个或多个用于解析值的资源包，这些值可以通过方法名称或通过注解上的显式 String 值来标识。这些位置是 Spring 资源位置字符串。

使用 @ExternalBean 注解的方法可以是具体的，在这种情况下，如果没有找到外部值，则将使用实际的返回值，如下所示： @ExternalValue public int otherNumber() { return 25; } 这种用法意味着该值是可外部化的，但外部化它是可选的，就像具有可用默认值的 bean 属性一样。

正如您所期望的那样，该示例的属性文件如下所示

底层机制被设计为可扩展的，因此属性文件不是唯一的选择，我们将在未来的版本中提供其他选项。抽象方法方法允许动态获取值：例如，来自数据库，或自定义，来自另一个系统。

现在，该示例仅适用于 SVN，但我们计划在本月发布 M3 版本。展望未来，位于西雅图的 Interface21 新顾问 Chris Beams 将负责这个项目。在 Interface21，我们相信我们所有的技术人员都应该做我们公司所做的一切：开发产品、咨询和培训。产品开发人员提供一些培训和咨询；服务交付人员参与项目。这确保了每个人都可以为我们都关心的开源项目做出贡献，并且每个人都扎根于现实世界的业务需求，而不是在光荣的孤立中开发基础设施（过去在 J2EE 中看到的一种危险）。Chris 主要从事咨询和培训工作，但他将与 Spring Java Config “对齐”，使其成为他的主要开发重点，因此他应该花费大量时间进行开发，并获得 Costin 和我的帮助。

Spring Java Config 需要多长时间才能达到 1.0 最终版，部分取决于您。我们需要关于实际使用情况的反馈；我们需要功能请求（尽管我们可能希望将范围保持在 1.0 的可管理范围内）；我们需要帮助确定优先级。如果您需要这个，请告诉我们，我们会倾听！