Understanding contexts in Spring MVC

问题:

I am new to spring and I am creating a simple web application. I have been reading about contexts in Spring MVC.

I am using STS plugin for eclipse. I created a Spring MVC project using the plugin.

Now I have three xml documents in the project, web.xml, root-context.xml and servlet-context.xml. These were created by STS for me.

1. In web.xml, dispatcher servlet is pointed towards servlet-context.xml and I understand the dispatcher servlets job is to create a web application context which knows how to resolve views and is a place for controller beans to exist. Is my understanding correct? If so, what other job is accomplished by this context?

2. Now, there is a file called root-context.xml which has a component scan on my projects default package. My understanding is this context needs to have global beans which many servlets might use. Is my understanding correct? What else does this do? What kind of context is created using this file?

3. Now, I am further along in the project and I have several *-context.xml files (dao-context.xml, security-context.xml etc) which are loaded using contextLoaderListner (in web.xml). Is this a good idea? Or should everything go into servlet-context.xml? I think it's a good idea to have different contexts as it provides separation of concern. Comments? Also, what kind of context is created from these *-context.xml files? What is the proper folder location for these files?

4. Web.xml is for the servlet container like tomcat etc and all other xml files in the project are for the spring container. Is that correct? All these files are separated to provide separation of concern?

5. How many application contexts and web application contexts exists in the current scenario?

Why would anyone need more than one dispatcher servlet?

Why would anyone need more than one application context?

Thoughts? Comments? Corrections? Best practices?

回答1:

The whole idea behind this design is to handle different architectural layers in a typical web application and provide for inheritance / override mechanism for beans across contexts. Each type of context in Spring is related to different architectural layer for e.g, web layer, service layer etc.

A Spring based web application can have multiple dispatcher servlet configured (although in majority of cases its a single servlet - but dispatcher serlvet is a servlet nonetheless and there could be multiple configured in web.xml). These can be configured to handle different url patterns. So obviously each is a different servlet and hence can have different Spring web Application context. Each of these can contain different configurations for Spring web layer like controllers,interceptors,view resolvers,locale resolvers etc. as these typically belong to the web layer of an application. All these configurations and beans are private to each dispatcher servlet so they are not visible to each other. Hence having a seperate spring web application context makes sense to enable this privacy. However there are other beans which are designed to be shared hence belong to a root context. So all the shareable things belong to the root context and it can be considered global for this web application.

Each dispatcher servlet inherits all the beans defined in the root context. However the important point to note is that the shared beans can be overridden by respective dispatcher servlet specific beans. So in web applications root context can be viewed as something which is inherited but can be overridden.

回答2:

Well spring does not force you to have xml files in that way, you can very well work everything using only one xml file that would be servlet-context.xml and using only dispatcher servlet. Generally there are different files in order to define your service beans or dao beans, so this basically depends on your application design, for eg if you are using spring security you might want to add one more xml file something like security-context.xml like as I said it depends on design. You can actually eliminate context loader listener completely and still manage to do everything using dispatcher servlet. Your question is too broad in scope, since you are new to spring may be you should get more details about spring containers and decide what suits your requirement. I generally have my servlet-context.xml in WEB-INF and other configuration like service-context.xml in classpath, again this is no strict rule just how it suits me.