如何制作多模块弹簧配置？ [英] How do you make a multi-module spring configuration?

问题描述

我有一个多模块（maven）弹簧版本。所有模块都发布了一些bean，并且大多数模块还使用依赖关系图中进一步定义的bean。虽然它的大部分是注释声明bean，但几乎每个模块都有一个或两个xml声明的bean。

I have a multi-module (maven) spring build. All the modules publish some beans, and most also consume beans defined further down the dependency graph. Although most of it is annotation declared beans, almost every module also has one or two xml-declared beans.

虽然我们有一个不太合适的解决方案，但我确实想知道在这种情况下组织xml文件的正确/最佳方式是什么？你在模块之间使用导入还是有其他方法？您是否将所有xml文件放在一个位置或根据依赖关系图将它们分散？你的解决方案如何处理部分弹簧上下文（典型的集成测试）？

Although we have a half-decent solution, but I am really wondering what is the correct/optimal way to organize the xml files in this scenario? Do you use import between the modules or is there some other way ? Do you put all the xml files in one place or spread them around according to the dependency graph? How does your solution handle partial spring contexts (typical integration tests) ?

我也希望这种组织方式能够让我最佳地利用IDE的弹簧支持（IDEA和一些eclipse用户）。

I'd also like to have this organized in a way that lets me leverage my IDE's spring support optimally (IDEA and a few eclipse users).

推荐答案

我们在模块中使用通配符导入以允许其他模块向模块提供bean声明导入：

We use wildcarded imports in the modules to allow other modules contribute beans to the module declaring the import:

<import resource="classpath*:com/acme/**/*-core-support.xml" />

模块性

想要贡献的模块对于主机，只需在 src / main / resources / com / acme 中放置一个正确命名的文件，以便自动获取。如果您使用类路径扫描（通过< context：component-scan /> ，它将变得更加容易）。

Modularity

Modules that want to contribute to the "host" just have to place a correctly named files in src/main/resources/com/acme in this case to be picked up automagically. If you use classpath scanning (by <context:component-scan /> it will become even easier).

在这方面有帮助的另一件事是一些小的Spring扩展，它接收给定类型的bean并再次在 ApplicationContext 中重新发布它们。通过这样做：

Another thing that helps in that regard is some small Spring extension that picks up beans of a given type and republishes them in ApplicationContext again. By doing something like this:

<plugin:list id="beanList" class="com.acme.MyCoolPluginInterface" />

<bean class="com.acme.MyPluginHost">
   <property name="plugins" ref="beanList" />
</bean>

结合通配导入，这将：

1. 收集实现 MyCoolPluginInterface 的 ApplicationContext 中找到的所有bean并将它们包装起来在 ApplicationContext 中注册为 beanList 的列表。


2. 允许 MyPluginHost 引用该列表。

1. Collect all beans found in the ApplicationContext that implement MyCoolPluginInterface and wrap them in a list registered as beanList in the ApplicationContext.
2. Allow the MyPluginHost to reference that list.

事实上，您现在只需扩展您的应用通过向类路径添加插件模块（也就是Maven中的依赖项）。

In fact, you now can simply extend your app by adding plugin modules to the classpath (aka dependency in Maven).

这个微小的Spring扩展称为Spring插件，并在Apache 2许可下发布。有关详细信息，请参阅 http://github.com/SpringSource/spring-plugin 。在Github上还有一个更高级的示例项目，展示了如何这有效并改善了GitHub的模块化。该应用程序是我的哎呀！我的架构在哪里？的示例代码。演示文稿，您可以在这里看到幻灯片或观看此处录制。

That tiny Spring extension is called Spring Plugin and published under Apache 2 licence. See http://github.com/SpringSource/spring-plugin for more info. There's also a more advanced sample project at Github, that shows how this works and improves modularity at GitHub. The app is sample code for my "Whoops! Where did my architecture go?" presentation which you can see the slides here or watch a recording here.

通常我们将应用程序配置为在目标环境中运行（使用JNDI查找和内容）。当然，您希望使用标准的 PropertyPlaceholderConfigurer 机制来外部化管理员必须触及的配置，或者在各种环境中进行更改。

Usually we configure our apps to run in the target environment (using JNDI lookups and stuff). Of course you would like to use the standard PropertyPlaceholderConfigurer mechanisms to externalize configuration that has to be touched by admins or will change through various environments.

对于集成测试，我们通常在 src / main / test 中有额外的配置文件，将另外加载到正常的配置文件覆盖将配置绑定到环境的关键bean。例如。如果您的普通配置文件中有数据源

For integration tests we usually have additional config files in src/main/test that get loaded additionally to the normal config files overriding the critical beans that tie the configuration to the environment. E.g. if you have a datasource in your normal config file

 <jee:jndi-lookup id="dataSource" jndi-name="jdbc/MyDataSource" />

您将在 test-context.xml 使用

 <bean id="dataSource" class="...DataSource" />
    <!-- config -->
 </bean>

并在测试类中原始之后导入

and importing that after the original one in the test class

 @ConfigurationContext(locations = {"app-context.xml", "test-context.xml"})
 public FooBarIntegrationtest {
   // ...
 }

这篇关于如何制作多模块弹簧配置？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！