Spring-MVC: What are a “context” and “namespace”?

Question

From XmlWebApplicationContext javadoc:

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").

What does it mean a Spring context?

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

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)?

Answer 1

"Spring context" = a 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.

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.

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.

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.

Answer 2

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 .

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.

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.

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