Spring XML 文件配置层次帮助/说明

Question

当我第一次开始学习 Spring 时，事情是在 applicationContext.xml 文件中配置的。然后，当我开始专门阅读有关 Spring 最新版本的书籍时，他们都在单独的 XML 文件中完成了配置，例如 myapp-servlet-xml、myapp-security.xml、myapp-service.xml 等，通过在 web.xml 文件中配置 contextConfigLocation。因此，例如，我一直在关注的代码有这个，因为它是 contextConfigLocation:

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /WEB-INF/myapp-servlet.xml
        /WEB-INF/myapp-data.xml
    </param-value>
</context-param>

无论如何，最近我遇到了一个配置问题(StackOverflow 上的有用人员帮我解决了这个问题)，这是由于这种分离造成的。这些书中的示例没有 applicationContext.xml 文件，后来当我尝试向应用程序添加自动扫描和注释时，这导致了问题。我尝试将所有内容移动到 applicationContext.xml 中并取消其他文件并解决了问题。没有其他改变，我只是把所有东西都放在 applicationContext.xml 中。

因此，这与其他人的评论一起使我明白，即使您不创建 applicationContext.xml，它仍会被使用，并且它是某种配置层次结构的顶层。我希望其他人可以向我解释这一切是如何运作的，因为我在任何地方都没有遇到过任何解释。

因此，例如，如果我将某些 context:component-scan 标记放入 applicationContext.xml 下方的配置文件中，则可能会导致某些类无法被扫描。那种性质的东西。我不明白优先级以及必须去哪里才能确保它在广泛的应用程序中被看到等等。如果有人可以清楚地解释它或向我指出解释它的资源，我将不胜感激，谢谢。希望我问的是有道理的。

Answer 1

名为“applicationContext.xml”的文件没有什么特别之处，只是 Spring 倾向于将其命名为默认配置文件。使用一个名为 that 的文件或多个名为“dog.xml”、“cat.xml”和“alien.xml”的文件的工作方式完全相同。您遇到的麻烦来自同时使用多个 ApplicationContext，而不是来自多个 XML 文件。我最近回答了一些因不理解这些概念而遇到问题的人的问题。查看这些答案，看看你还有什么问题:

Declaring Spring Bean in Parent Context vs Child Context

Spring-MVC: What are a "context" and "namespace"?

编辑:回答你的新问题:

I had a <context:component-scan base-package="com.myapp"/> tag in my servlet.xml.

我猜这个“servlet.xml”文件的名字是 foo-servlet.xml ，在你的 web.xml 中配置的 DispatcherServlet 被命名为“foo”，比如

<servlet>
    <servlet-name>foo</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>

按照惯例，当这个 DispatcherServlet 启动时，它会创建一个由文件 foo-servlet.xml 配置的新 ApplicationContext。 ，源自 servlet-name .现在，由于您输入了 context:component-scan在那里，它将递归扫描给定的包并为所有带注释的类创建 bean。你给的包裹， com.myapp , 看起来它是整个应用程序的基本包，因此 Spring 将从应用程序中所有带注释的类创建 bean，包括数据访问类，在与 DispatcherServlet 关联的这个 ApplicationContext 中。通常，这个上下文应该只有 View 层的东西和直接支持其中的 DispatcherServlet 的 bean，所以这是一个错误的配置。

In my data.xml file I had data source beans and that was it. No other beans, everything else was autowired and annotated.

据推测，这个“data.xml”文件就是您在 contextConfigLocation 中列出的文件。上下文参数。假设您还将 ContextLoaderListener 添加到您的 web.xml ， 喜欢

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

然后该文件将用于创建第二个 ApplicationContext——根上下文。这就是这个听众所做的。请注意，它实际上从 contextConfigLocation 中列出的所有文件构建上下文。 ，并且如果您还在该列表中包含了“servlet.xml”，那么您已经加载了该配置两次:在根上下文中以及在与 DipatcherServlet 关联的上下文中。希望您现在看到了 XML 配置文件和它们配置的 ApplicationContext 之间的明显区别。可以轻松地使用同一个 XML 文件来配置两个不同的上下文。这样做是否正确是另一个问题。在这种特殊情况下，它不是。

我描述这两个上下文的顺序实际上是倒退的。我只是按照你对你所做的事情的描述。 ContextLoaderListener，是一个 ServletContextListener , 将始终在任何 servlet 启动之前执行。这意味着首先创建根上下文，然后创建另一个上下文。这是设计使然，当 DispatcherServlet 创建其上下文时，它可以将该上下文添加为根上下文的子级。我在其他帖子中描述了这种关系。这样做的最重要的效果是根上下文中的 bean 可通过 DispatcherServlet 的上下文使用。这也适用于 Autowiring 的关系。这很重要，因为 DispatcherServlet 只在其关联的上下文中查找它需要的 bean，例如 Controller 实例。但是，您的 Controller 显然必须与支持 bean 连接。因此，传统上， Controller 位于 DispatcherServlet 的上下文中，支持 bean 位于根上下文中。

I then tried to add @Transacational to my service bean and it wouldn't persist.

为了使@Transactional 工作，您必须包含 <tx:annotation-driven/>注释 bean 所在的 ApplicationContext 配置中的标记。诀窍是弄清楚“它住在哪里”部分。子级中的 Bean 可以覆盖父级上下文中的 Bean。因此——我只是在这里猜测——如果你像我上面描述的那样将所有的 bean 加载到 DispatcherServlet 上下文中，但把 <tx:annotation-driven/>在根上下文中，您可能在根上下文中有一个正确事务性的 bean，但它不是正在使用的 bean，因为副本“更接近”父/子层次结构中的 servlet，并且它所在的上下文没有得到一个 <tx:annotation-driven/>配置。

When I changed the servlet context:component-scan tag to instead point at com.myapp.web and then added a context:component-scan tag to the data.xml file, everything worked.

它仍然在某种程度上取决于您将哪些配置文件包含在哪些 ApplicationContext 中，但至少我可以说，通过这样做，您从 DispatcherServlet 的上下文中删除了许多导致问题的 bean。特别是，您在根上下文中正确配置的 @Transactional bean 将不再被子上下文中的 bean 遮蔽，并且会被注入(inject)到您的 Controller 中，因此您的持久性内容将起作用。

所以...要带走的主要事情是你有两个相关的 ApplicationContexts。您必须始终意识到这一事实，并控制哪些 bean 出现在哪个上下文中。

这是否涵盖所有内容？