我有一个多模块（maven）弹簧构建。所有模块都发布了一些 bean，并且大多数模块还使用了在依赖关系图中进一步定义的 bean。虽然大部分是注解声明的bean，但几乎每个模块也都有一两个xml声明的bean。
虽然我们有一个半体面的解决方案，但我真的想知道在这种情况下组织 xml 文件的正确/最佳方式是什么？您是在模块之间使用导入还是有其他方式？你是把所有的 xml 文件放在一个地方还是根据依赖关系图分散它们？您的解决方案如何处理部分 spring 上下文（典型的集成测试）？
我还希望以一种可以让我最佳地利用我的 IDE 的 spring 支持（IDEA 和一些 eclipse 用户）的方式来组织它。
【问题讨论】：
我们在模块中使用通配符导入以允许其他模块向声明导入的模块贡献 bean：
<import resource="classpath*:com/acme/**/*-core-support.xml" />
想要贡献给“主机”的模块只需要在src/main/resources/com/acme 中放置一个正确命名的文件，在这种情况下就会被自动拾取。如果你使用类路径扫描（<context:component-scan /> 会变得更容易）。
在这方面有帮助的另一件事是一些小的 Spring 扩展，它拾取给定类型的 bean 并再次在 ApplicationContext 中重新发布它们。通过这样做：
<plugin:list id="beanList" class="com.acme.MyCoolPluginInterface" />
<bean class="com.acme.MyPluginHost">
<property name="plugins" ref="beanList" />
</bean>
结合通配符导入，这将：
ApplicationContext 中找到的所有实现MyCoolPluginInterface 的bean，并将它们包装在ApplicationContext 中注册为beanList 的列表中。MyPluginHost 引用该列表。事实上，您现在可以通过将插件模块添加到类路径（在 Maven 中也称为依赖项）来简单地扩展您的应用程序。
这个小小的 Spring 扩展被称为 Spring Plugin，并在 Apache 2 许可下发布。请参阅http://github.com/SpringSource/spring-plugin 了解更多信息。 Github 上还有一个更高级的 sample project，它展示了它是如何工作的，并在 GitHub 上改进了模块化。该应用程序是我的“哎呀！我的架构去哪儿了？”的示例代码。您可以查看slides here 或观看recording here 的演示文稿。
通常我们将应用程序配置为在目标环境中运行（使用 JNDI 查找等）。当然，您希望使用标准的PropertyPlaceholderConfigurer 机制来外部化管理员必须接触或将在各种环境中更改的配置。
对于集成测试，我们通常在src/main/test 中有额外的配置文件，它们会额外加载到普通配置文件中覆盖将配置与环境联系起来的关键bean .例如。如果您的普通配置文件中有数据源
<jee:jndi-lookup id="dataSource" jndi-name="jdbc/MyDataSource" />
您可以在test-context.xml 中使用
<bean id="dataSource" class="...DataSource" />
<!-- config -->
</bean>
并在测试类中在原来的那个之后导入
@ConfigurationContext(locations = {"app-context.xml", "test-context.xml"})
public FooBarIntegrationtest {
// ...
}
【讨论】：
我们只是根据使用情况从多个 XML 配置文件创建应用程序上下文。
例如，对于没有服务器的测试，上下文是通过使用每个服务模块中的所有配置文件来创建的。
部署后，我们通过 Spring Remoting 访问服务，因此客户端使用通过 XML 配置初始化的应用程序上下文，该配置定义了启用远程处理的代理 bean。同时，服务由测试用例使用的相同 XML 文件配置，但应用程序上下文现在由 DispatcherServlet 或 EJB 或 MDB 加载。
此设置允许我们为每个场景定制应用程序上下文，而无需在配置文件中复制任何信息，从而使维护更加简单。此外，通过导入在配置文件之间没有硬依赖，因为这是在实际创建 ApplicationContext 的上层处理的。
无法评论 IDE 支持，因为我们还没有使用它。
【讨论】：