Spring-MVC：什么是“上下文”和“命名空间”？

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

提问by rapt

From XmlWebApplicationContextjavadoc:

来自XmlWebApplicationContextjavadoc：

By default, the configuration will be taken from "/WEB-INF/applicationContext.xml" for the root context, and "/WEB-INF/test-servlet.xml" for a context with the namespace "test-servlet" (like for a DispatcherServlet instance with the servlet-name "test").

默认情况下，配置将从“/WEB-INF/applicationContext.xml”获取根上下文，从“/WEB-INF/test-servlet.xml”获取命名空间为“test-servlet”的上下文（如对于具有 servlet 名称“test”的 DispatcherServlet 实例）。

What does it mean a Spring context?

Spring上下文是什么意思？

What is the root context? What other kinds of Spring context are there?

什么是根上下文？还有哪些其他类型的 Spring 上下文？

What is a namespace?

什么是命名空间？

UPDATE:

更新：

Some follow-up questions:

一些后续问题：

1. What is a Spring ApplicationContext - is it some "thing" that holds the beans that are defined in a configuration XML file?

2. Looking at the code of ContextLoaderListener, it looks like it loads the data defined in the config XML file(s). But my Spring web app works without defining this listener or any other listener. How could it be?

3. In what scenarios would it make sense to have more than one instance of Spring's DispatcherServlet?

4. Is the root context (data from applicationContext.xml) applicable to every instance of DispatcherServlet, while other contexts (e.g. data from test-servlet.xml) applicable only to the relevant DispatcherServlet (i.e. test)?

1. 什么是 Spring ApplicationContext - 它是一些保存在配置 XML 文件中定义的 bean 的“东西”吗？

2. 查看 ContextLoaderListener 的代码，它看起来像是加载了配置 XML 文件中定义的数据。但是我的 Spring Web 应用程序无需定义此侦听器或任何其他侦听器即可工作。怎么会这样？

3. 在什么情况下，拥有多个 Spring 的 DispatcherServlet 实例是有意义的？

4. 根上下文（来自 applicationContext.xml 的数据）是否适用于 DispatcherServlet 的每个实例，而其他上下文（例如来自 test-servlet.xml 的数据）仅适用于相关的 DispatcherServlet（即测试）？

采纳答案by Ryan Stewart

"Spring context" = a Spring ApplicationContext.

“Spring 上下文” = 一个Spring ApplicationContext。

"root context", in terms of a web application, means the main context that's loaded and used by the webapp. Typically, you'll start the root context with a ContextLoaderListener.

“根上下文”，就 Web 应用程序而言，是指 Web 应用程序加载和使用的主要上下文。通常，您将使用ContextLoaderListener启动根上下文。

The root context isn't really a "kind" of context. It's just a role that a context plays. You have one root context in a webapp. Other contexts are not the root context. They're usually children of the root context.

根上下文并不是真正的“种类”上下文。这只是上下文所扮演的角色。您在 web 应用程序中有一个根上下文。其他上下文不是根上下文。它们通常是根上下文的子级。

A namespace here refers to the scope of an instance of Spring's DispatcherServlet. All it's saying right there is that if you name your servlet "test" in your web.xml, then by convention, Spring will look for a file named "test-servlet.xml" to use as that dispatcher's context. Incidentally, each context like this which is created for a dispatcher becomes a child of the root context.

这里的命名空间是指 Spring 的 DispatcherServlet 实例的范围。它的意思是，如果您在 web.xml 中将 servlet 命名为“test”，那么按照惯例，Spring 将查找名为“test-servlet.xml”的文件以用作该调度程序的上下文。顺便说一句，像这样为调度程序创建的每个上下文都成为根上下文的子级。

Edit:To answer your new questions:

编辑：要回答您的新问题：

1. Follow the link in the first line of my answer to learn about the ApplicationContext. If you have questions not answered there, I'd suggest posting a new SO question.
2. The root context is optional. If you don't have the ContextLoaderListener defined, then you just don't have a root context. When you use a DispatcherServlet, it starts its own ApplicationContext, and it will get the beans it needs from there.
3. I don't know of one off the top of my head. I suppose if there were a need for drastically different configurations between some of the URL resources in your app, that might drive you to do it.
4. Yes. To state it in the proper terms, the root context is the parent context of any context started for a DispatcherServlet. Beans in a parent context are accessible through and by the child context, but the reverse isn't true.

1. 按照我的答案第一行中的链接了解 ApplicationContext。如果您有没有在那里回答的问题，我建议发布一个新的 SO 问题。
2. 根上下文是可选的。如果您没有定义 ContextLoaderListener，那么您就没有根上下文。当您使用 DispatcherServlet 时，它会启动自己的 ApplicationContext，并从那里获取所需的 bean。
3. 我不知道我的头顶上有一个。我想如果您的应用程序中的某些 URL 资源之间需要完全不同的配置，那可能会促使您这样做。
4. 是的。用正确的术语来表述它，根上下文是为 DispatcherServlet 启动的任何上下文的父上下文。父上下文中的 Bean 可以通过子上下文访问，但反之则不然。

回答by hellojava

In a web application, the architecture is usually divided into layers like the popular MVC structure. So a web app comprises basically of a layer that handles the client requests i.e HTTPRequests and a layer that services those requests .

在 Web 应用程序中，架构通常像流行的 MVC 结构一样被划分为层。因此，Web 应用程序基本上由处理客户端请求（即 HTTPRequests）的层和为这些请求提供服务的层组成。

To summarize : classes that are meant to handle the Http requests i.e the controllers which are mapped to urls come under the test-servlet.xml. This is called as WebapplicationContext containing only the beans that are required mainly to handle the client requests.

总结一下：用于处理 Http 请求的类，即映射到 url 的控制器位于 test-servlet.xml 下。这称为 WebapplicationContext 仅包含主要用于处理客户端请求所需的 bean。

Now the next part is the Service/Dao layer that comprises of your business logic. Beans that perform such logic are loaded under ApplicationContext object.

现在下一部分是包含您的业务逻辑的 Service/Dao 层。执行此类逻辑的 Bean 加载在 ApplicationContext 对象下。

Now you may ask why have they separated these things in to files or two different objects.

现在您可能会问为什么他们将这些东西分成文件或两个不同的对象。

Its because, an application have the same business logic that can be used by multiple clients working on different protocol. You may use the same service layers to handle RMI as well as HTTP calls. So Spring created a parent context that is started us as an ApplicationContext. And then if your applicationhandles web requests, you can create a dispathcher servlet which has its own Webapplicationcontext and initialized as a child of the parent context. So all the parent beans can be referenced in the child and can be overiden but not vice versa

这是因为，一个应用程序具有相同的业务逻辑，可以被多个使用不同协议的客户端使用。您可以使用相同的服务层来处理 RMI 和 HTTP 调用。所以 Spring 创建了一个父上下文，作为 ApplicationContext 启动我们。然后，如果您的应用程序处理 Web 请求，您可以创建一个调度程序 servlet，它具有自己的 Webapplicationcontext 并初始化为父上下文的子级。所以所有父bean都可以在子bean中引用并且可以被覆盖，反之亦然