17

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?

Abhishek Shukla Ravishankara
  • 613
  • 10
  • 17

2 Answers2

16

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.

Shailendra
  • 8,874
  • 2
  • 28
  • 37
  • thanks. I think I am beginning to understand. How is the root application context different from (or related to) the contexts defined in each of the xml files? – Abhishek Shukla Ravishankara Oct 27 '13 at 18:45
  • 1
    In web application, the root context which is typically initialized using ContextLoaderListener stores the root context in a Servlet context (application scoped) variable named WebApplicationContext.class.getName() + ".ROOT" and henceforth each dispatcher serlvet (or for that matter any code) can internally access this attribute if it has access to servlet context – Shailendra Oct 27 '13 at 18:56
  • got it! So these xml files, dao-context.xml service-context.xml create more contexts or just add to the root context created by the contextLoaderListener? What is the scope of these xml files? – Abhishek Shukla Ravishankara Oct 27 '13 at 18:59
  • You can either provide a single xml file and use import tag inside the xml file to import different context file like dao-context.xml or you can provide comma seperated different xml files,or use classpath prefixes - its a matter of choice. However all of these would be in a single root context. The use of different xml files in this case is usaully only from perspective of modularity and seperation of concerns. – Shailendra Oct 27 '13 at 19:08
  • Any specific reason why this answer was accepted and then unaccepted ? – Shailendra Oct 29 '13 at 03:36
  • 1
    U can find nice explanation here also, [link](http://www.codesenior.com/en/tutorial/Spring-ContextLoaderListener-And-DispatcherServlet-Concepts) – Nilesh Aug 27 '17 at 17:00
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.

varun
  • 684
  • 1
  • 11
  • 30
  • Yes, I understand that it is design based. I was trying understand more on the terms of actual contexts created when I have my application designed the way I have explained. For eg, the dispatcher servlet creates a web application context where your web stuff should reside. Context loader listener creates an application context. How do these two work together? Is there only one application context which has all those beans from the xml files or for each xml file an application context is created? – Abhishek Shukla Ravishankara Oct 27 '13 at 16:38
  • Number of contexts created does not depend on number of files. DispatcherServlet is created as child context. – varun Oct 27 '13 at 18:24
  • Child context of what? – Abhishek Shukla Ravishankara Oct 27 '13 at 18:42
  • Of the root context. You can configure as many dispatcher servlet as you want but there is always a single root context. The beans in root context can be accessed in all child contexts. Sometimes we configure more than one dispatcher servlet for eg if we can configure another dispatcher servlet for our rest services. – varun Oct 27 '13 at 19:26