Multiple application context, multiple dispatcher servlets?

Question

Until now I used to think that a web-application can have only one dispatcher-servlet which we define in web.xml

• Am I right in th

Answer 1

Can you have multiple dispatcher servlets in a single web application ?

Of course, quoting the official documentation (bold is actually there as well!)

A web application can define any number of DispatcherServlets. Each servlet will operate in its own namespace, loading its own application context with mappings, handlers, etc. Only the root application context as loaded by ContextLoaderListener, if any, will be shared.

---

How?

Just declare several servlets with different names but using org.springframework.web.servlet.DispatcherServlet class. Also make sure yourServletName-servlet.xml file is available.

---

What is a situation we might need this in ?

DispatcherServlet is very flexible. Not only Spring MVC uses it, but also Spring WS, Spring support for hessian, etc.

---

Also, can there only be a single application context in the entire web application ?

Answered already, also in the quoted documentation: one application context per DispatcherServlet + one main web application context.

---

How can we define multiple application contexts ?

See above, just create multiple DispatcherServlets.

---

Can a dispatcher servlet exist in a non-spring application ?

DispatcherServlet is a Spring context (Spring application) on its own, thus: no. On the hand DispatcherServlet can be declared in an application not having parent (main) application context, thus: yes.

Answer 2

What is a situation we might need this in ?

^_OR
Advantages of multiple dispatcher servlets ^_OR
Why we need multiple dispatcher servlets?

Simple answer is to have DispatcherServlet's functionality in several forms

Dispatcher servlet functionality

---

• Dispatcher Servlet uses HandlerMapping implementation to control the routing of requests to handler objects. Default is BeanNameUrlHandlerMapping and RequestMappingHandlerMapping.
• It's view resolution strategy can be specified via a ViewResolver implementation, resolving symbolic view names into View objects. Default is InternalResourceViewResolver.
• It's exception resolution strategy can be specified via a HandlerExceptionResolver, for example mapping certain exceptions to error pages.
• It's strategy for resolving multipart requests is determined by a MultipartResolver implementation.
• It's locale resolution strategy is determined by a LocaleResolver.
• It's theme resolution strategy is determined by a ThemeResolver.

---

I will try to explain some of the functionalities provided by DispatcherServlet

Declaring Multiple dispatcher servlets
Consider we have two dispatcher servlets(DS) where DS1, DS2 are configured with different url patterns(**.simple, **.beanName) and they uses different dispatcher servlet configuration provided as given below.

DispatcherServlet     - simpleUrlHandlerDispatcherServlet
contextConfigLocation - /WEB-INF/simpleUrlHandlerMapping.xml
<url-pattern>*.simple</url-pattern>

DispatcherServlet     - beanNameUrlHandlerDispatcherServlet
contextConfigLocation - /WEB-INF/beanNameUrlHandlerMapping.xml
<url-pattern>*.beanName</url-pattern>

^{_{Advantage 1:}} We can have different HandlerMapping for different set of URL

DS1 bean name url handler mapping configuration

<bean name="/hello.beanName" class="com.pvn.mvc.HelloController" />
<bean name="/hi.beanName" class="com.pvn.mvc.HiController" />

DS2 simple url handler mapping configuration

<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="mappings">
        <props>
            <prop key="/hello.simple">simpleHello</prop>
            <prop key="/hi.simple">simpleHi</prop>
        </props>
    </property>
</bean>

^{_{Advantage 2:}} We can have different view resolver for different set of URL's.

InternalResourceViewResolver for DS1
where it deals with only prefix + returned String + suffix.
TilesViewResolver for DS2
its implementation provided by apache tiles which is a layout/skeleton based plugin high level functionality as given below.
Or if we use TilesViewResolver with different layout for different set of URL's
anonymous user - different layout
logged in user - different layout

^{_{Advantage 3:}} We can have different theme resolver for different set of URL's.
These resolver continuously monitors cookie/session to resolve theme and serves stylesheet/theme qualified (as given in below image). Below given just an example for outcome of CookieThemeResolver.
Note: This is not about theme configuration but about theme resolver configuration.

^{_{Advantage 4:}} We can have different locale resolver for different set of URL's.
These resolver continuously monitors cookie/session/accept-header to resolve locale and loads application message qualified(as given in below image). Below given just an example for outcome of CookieLocaleResolver.
Note: This is not about locale configuration but about locale resolver configuration.