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

这两种配置方法截然不同：Spring Framework 中的 @Autowired 注解使用业务对象中的注解来配置组件，而 Spring Java Config 采用了一种独特的方法，将注解外部化到专门的配置类中。这两种方法本身并没有绝对的对错之分，它们在不同的情况下都具有优势。甚至可以在同一个应用程序中同时使用这两种方法。

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

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

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

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

由于 Costin 致力于Spring 用于 OSGi 的动态模块，Spring Java 配置有一段时间进展缓慢，但现在它已经步入正轨。在过去的几天里，我做了一些工作：将其更新到 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 方法的返回值。）这些方法可以是公共的或受保护的。

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

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

正如您所料，示例的属性文件如下所示

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

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

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