如何安排 spring 上下文配置文件,使其与项目依赖项相匹配?

发布于 2024-12-19 18:33:17 字数 1394 浏览 6 评论 0原文

我有一个网络应用程序,它依赖于其他两个模块。
为了简单起见,我们将它们称为 ServiceA 模块和 ServiceB 模块。
每个模块都有各种不同的依赖项,并且还对 Entities 模块有一个共同的依赖项。
上述每个模块都声明了自己的 spring 上下文文件,其中包含与其范围相关的信息。
我现在正在尝试决定如何在项目之间“连接”这些配置文件,但我有点困惑。

我知道一种选择是在网络应用程序的 web.xml 中声明所有“结束”文件(即 ServiceA、ServiceB 和实体)(在 contextConfigLocation 参数中),但我不这样做喜欢这个选项,特别是因为我的实际用例更复杂并且具有更多共享的内部依赖项。

我最初的意图是在 contextConfigLocation 参数中仅声明 ServiceAServiceB 的配置文件,因为这些是 Web 应用程序唯一使用的项目直接依赖(通过查看 maven pom 很容易看出),然后让 ServiceAServiceB 将此指令包含在它们的 spring 上下文配置文件中<代码><导入资源=“classpath:EntitiesContext.xml”>。这种方法的优点是它与 Maven 传递方法一致,在这种方法中,我声明我所依赖的内容,并且如果该模块依赖于某些东西,它会将其拖到一起。这种方法的问题是我在这里阅读 Entities 模块中的所有 bean 将被创建两次(尽管最后只保留一个实例),这是一项昂贵且不必要的操作。

我非常想听听人们如何解决这个用例,因为我认为我没有遇到任何极端情况。

谢谢

更新 我最终使用的语法是 classpath*:META-INF/*/*Context.xml 因为 Thomasz 建议的语法存在一些问题。
如需更多阅读,请参阅 spring 的错误报告(部分解决了该问题)和博客文章关于这个问题

I have a web-application which is dependent on two other modules.
For simplicity let's call them ServiceA module and ServiceB module.
Each of these modules has various different dependencies and also a common dependency on the Entities module.
Each of the above mentioned modules declares its own spring context file with information pertaining to its scope.
I'm trying now to decide how to "wire" these configuration files between the projects and I'm a bit stumped.

I know one option is just to declare all the "end" files (i.e. ServiceA, ServiceB and Entities) in the web.xml of the web-app (in the contextConfigLocation param) but I don't like that option particularly since my actual use-case is more complex and has more internal dependencies which are shared.

My original intent was to declare in the contextConfigLocation param only the config files for ServiceA and ServiceB since these are the only projects which the web-app is directly dependent upon (this is easy to see by looking at the maven pom), and then have both ServiceA and ServiceB to include this directive in their spring context configuration file <import resource="classpath:EntitiesContext.xml">. The advantage with this approach is that it is consistent with the maven transitive approach where I declare what I'm dependent upon and if that module is dependent upon something it will drag it along with it. The problem with this approach is that I read here that all the beans in the Entities module will be created twice (although only one instance will remain at the end) which is an expensive and unneeded action.

I'd like very much to hear how people solve this use-case since I don't think I've hit any corner case.

Thanks

Update
The syntax I ended up using was classpath*:META-INF/*/*Context.xml since there are some issues with the syntax Thomasz suggested.
For additional reading see the bug report of spring (which partially resolved the issue) and a blog post regarding the issue

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

浊酒尽余欢 2024-12-26 18:33:18

您是否考虑过使用 基于注释的配置

这应该可以让您将 XML 配置的大小减少到几行。

或者,使用顶级 基于 Java 的配置将允许您以受控方式拉入您想要的部分(无需搜索整个类路径),并且没有任何重复的 bean 或任何 XML 文件。

Have you considered using an annotation based configuration?

That should allow you to reduce the size of your XML config to just a few lines.

Alternatively, using top-level Java based config would allow you to pull in the parts that you want in a controlled way (without having to search the whole classpath) and without any duplicate beans or any XML files.

才能让你更想念 2024-12-26 18:33:17

遵循配置文件的一些命名约定并简单地选取 CLASSPATH 上可用的所有内容怎么样?

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        classpath*:*Context.xml 
    </param-value>
</context-param>

该解决方案假设显然所有必需的模块都在 CLASSPATH 上,但不存在非必需的模块。

What about following some naming convention of config files and simply picking up all that are available on the CLASSPATH?

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        classpath*:*Context.xml 
    </param-value>
</context-param>

This solution assumes that obviously all required modules are on the CLASSPATH but also that non-required modules aren't there.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文