Difference between applicationContext.xml and spring-servlet.xml in Spring Framework

Question

• Are applicationContext.xml and spring-servlet.xml related anyhow in Spring Framework?
  
• Will the properties files declared in applicationContext.xml be available to DispatcherServlet?
  
• On a related note, why do I need a *-servlet.xml at all? Why is applicationContext.xml alone insufficient?

Grani

See this as well. #11709467 – Septuagesima

Answer 1

Spring lets you define multiple contexts in a parent-child hierarchy.

The applicationContext.xml defines the beans for the "root webapp context", i.e. the context associated with the webapp.

The spring-servlet.xml (or whatever else you call it) defines the beans for one servlet's app context. There can be many of these in a webapp, one per Spring servlet (e.g. spring1-servlet.xml for servlet spring1, spring2-servlet.xml for servlet spring2).

Beans in spring-servlet.xml can reference beans in applicationContext.xml, but not vice versa.

All Spring MVC controllers must go in the spring-servlet.xml context.

In most simple cases, the applicationContext.xml context is unnecessary. It is generally used to contain beans that are shared between all servlets in a webapp. If you only have one servlet, then there's not really much point, unless you have a specific use for it.

Ammonic

why would you have multiple spring servlets ? – Scoff

About your comment All Spring MVC controllers must go in the spring-servlet.xml context., where can I find in the official Spring reference? – Rodolforodolph

@CKLee, when I move them into the root application context, Spring MVC does not process any @RequestMapping. At least, that's what I remembered, and a quick test confirmed that. However, some have no issues moving the scanning of @Controller into the root context, it seems, so I might be wrong. – Adp

mighty potent answer (because of succinctness) – Deservedly

@Scoff it is sometimes useful to separate parts of your application that could otherwise conflict in the same context. As an example you may have ReST services and standard views, you may then have different view resolvers or security concerns for the services as to the views. – Interrogative

People should see this answer before reading documentation and developing apps! In normal cases there is no need to have ContextLoaderListener and contextConfigLocation at all, just DispatcherServlet! – Cyril

In many tutorials contextConfigLocation contains dispatcher-servlet.xml as well as DispatcherServlet. This causing beans to be initialized twice! – Cyril

ruruskyi The statement about putting everything into one context is only skaffman's opinion, the official STS team approach is described in Raje's answer. I see no reason to put everything together especially because AOP do not play well with controller. If you use Spring Security for example using method security with dispatcher servlet is strongly discouraged. This answer is four years old after all. – Beitris

@Scoff I like your question and I upvoted it. why would you have multiple spring servlets ? It took me a while to figure out this context structure and having done so I am left wondering if anyone actually uses it. For myself, if I have two services I will put them in different .war files so that I can deploy them separately. It seems like someone went to a lot of trouble to create this servlet/mvc "feature". But for me it is a overly complex with a low amount of utility. – Parkman

@Matt Friedman: even if you do not have multipe servlets there are reasons to use the two contexts: see #9016622 – Ploy

where does web.xml comes into picture then? – Cheesecloth

"Beans in spring-servlet.xml can reference beans in applicationContext.xml". Can you explain how? Link to any example? – Hudis

Answer 2

Scenario 1

In client application (application is not web application, e.g may be swing app)

private static ApplicationContext context = new  ClassPathXmlApplicationContext("test-client.xml");

context.getBean(name);

No need of web.xml. ApplicationContext as container for getting bean service. No need for web server container. In test-client.xml there can be Simple bean with no remoting, bean with remoting.

Conclusion: In Scenario 1 applicationContext and DispatcherServlet are not related.

Scenario 2

In a server application (application deployed in server e.g Tomcat). Accessed service via remoting from client program (e.g Swing app)

Define listener in web.xml

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

At server startup ContextLoaderListener instantiates beans defined in applicationContext.xml.

Assuming you have defined the following in applicationContext.xml:

<import resource="test1.xml" />
<import resource="test2.xml" />
<import resource="test3.xml" />
<import resource="test4.xml" />

The beans are instantiated from all four configuration files test1.xml, test2.xml, test3.xml, test4.xml.

Conclusion: In Scenario 2 applicationContext and DispatcherServlet are not related.

Scenario 3

In a web application with spring MVC.

In web.xml define:

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

<servlet-mapping>
    <servlet-name>springweb</servlet-name>
    <url-pattern>*.action</url-pattern>
</servlet-mapping>

When Tomcat starts, beans defined in springweb-servlet.xml are instantiated. DispatcherServlet extends FrameworkServlet. In FrameworkServlet bean instantiation takes place for springweb . In our case springweb is FrameworkServlet.

Conclusion: In Scenario 3 applicationContext and DispatcherServlet are not related.

Scenario 4

In web application with spring MVC. springweb-servlet.xml for servlet and applicationContext.xml for accessing the business service within the server program or for accessing DB service in another server program.

In web.xml the following are defined:

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

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

<servlet-mapping>
    <servlet-name>springweb</servlet-name>
    <url-pattern>*.action</url-pattern>
</servlet-mapping>

At server startup, ContextLoaderListener instantiates beans defined in applicationContext.xml; assuming you have declared herein:

<import resource="test1.xml" />
<import resource="test2.xml" />
<import resource="test3.xml" />
<import resource="test4.xml" />

The beans are all instantiated from all four test1.xml, test2.xml, test3.xml, test4.xml. After the completion of bean instantiation defined in applicationContext.xml, beans defined in springweb-servlet.xml are instantiated.

So the instantiation order is: the root (application context), then FrameworkServlet.

Now it should be clear why they are important in which scenario.

Jeraldjeraldine

+1. Very good.I was looking for this type of comparison, but never found. – Spirituous

@abishkar bhattarai very good, my question is: so what is if using @ Component and @ Value annotation to create bean when "Scenario 4" – Lacefield

springweb DispatcherServlet will not called if the url not ends with .action? – Hollo

@Lacefield You will still have to specify the class path in the springweb-servlet.xml so that Spring can find that component in its scan. – Washhouse

Answer 3

One more point I want to add. In spring-servlet.xml we include component scan for Controller package. In following example we include filter annotation for controller package.

<!-- Scans for annotated @Controllers in the classpath -->
<context:component-scan base-package="org.test.web" use-default-filters="false">
    <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

In applicationcontext.xml we add filter for remaining package excluding controller.

<context:component-scan base-package="org.test">
        <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
    </context:component-scan>

Kythera

why ? Why not just scan the whole thing one time ? – Scoff

@Scoff You have to scan @Controller beans in servlet context (required by Spring MVC). – Actinic

Why not can the whole thing twice? Why include/exclude? – Verleneverlie

One should also add use-default-filters="false" attribute in spring-servlet.xml – Karykaryl

Rakesh Waghela has point. Without that attribute Controller beans will be created twice. Firstly in appContext and secondly in servletContext – Ambulant

@MikeRylander this will create chaos as the beans will be scanned and created twice. For example if you have DAO/Repository beans they will be duplicated and those that are in the servlet contexts will run without transactions(as transaction AOP is usually done only declared in the root context) or Spring method security (if security is not declared in the servlet context explicitly) – Beitris

Why not create separate package for each category? and com.abc.controller, com.abc.dao then don't need to filter? – Hollo

Answer 4

In simple words,

applicationContext.xml defines the beans that are shared among all the servlets. If your application have more than one servlet, then defining the common resources in the applicationContext.xml would make more sense.

spring-servlet.xml defines the beans that are related only to that servlet. Here it is the dispatcher servlet. So, your Spring MVC controllers must be defined in this file.

There is nothing wrong in defining all the beans in the spring-servlet.xml if you are running only one servlet in your web application.

Brei

I can define all the beans in spring-servlet.xml, but there also should be applicationContext.xml that may be empty (without beans) in this case. Correct? – Grapnel

Answer 5

In Servlet technology if you want to pass any input to a particular servlet then you need to pass in init param like below code.

 <servlet>
    <servlet-name>DBController</servlet-name>
    <servlet-class>com.test.controller.DBController</servlet-class>
    <init-param>
        <param-name>username</param-name>
        <param-value>John</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>DBController</servlet-name>
    <url-pattern>/DBController</url-pattern>
</servlet-mapping>

If you want to pass some in put that is common for all servlets then that time you need to configure context param. Example

 <context-param>
    <param-name>email</param-name>
    <param-value>[email protected]</param-value>
</context-param>

SO exactly like this when ever we are working with Spring MVC we need to provide some information to Predefined servlet provided by Spring that is DispatcherServlet through init param. So the configuration is as fallows, here we are providing the spring-servlet.xml as init parameter to DispatcherServlet.

 <?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
              http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    id="WebApp_ID" version="3.0">
    <display-name>Spring MVC App</display-name>

    <servlet>
        <servlet-name>SpringController</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>/WEB-INF/spring-servlet.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>SpringController</servlet-name>
        <url-pattern>*.htm</url-pattern>
    </servlet-mapping>
</web-app>

Again we need some context param. That is applicable for whole application. So we can provide the root context that is applicationcontext.xml The configuration is like this:

    <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/applicationcontext.xml</param-value>
</context-param>
<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<servlet>
        <servlet-name>SpringController</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>/WEB-INF/spring-servlet.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>SpringController</servlet-name>
        <url-pattern>*.htm</url-pattern>
    </servlet-mapping>

Haggle

Answer 6

Application contexts provide a means for resolving text messages, including support for i18n of those messages. Application contexts provide a generic way to load file resources, such as images. Application contexts can publish events to beans that are registered as listeners. Certain operations on the container or beans in the container, which have to be handled in a programmatic fashion with a bean factory, can be handled declaratively in an application context. ResourceLoader support: Spring’s Resource interface us a flexible generic abstraction for handling low-level resources. An application context itself is a ResourceLoader, Hence provides an application with access to deployment-specific Resource instances. MessageSource support: The application context implements MessageSource, an interface used to obtain localized messages, with the actual implementation being pluggable

Barrett