When do we need multiple Dispatcher Servlet?

In which scenarios, we need multiple Dispatcher-Servlets?
Can anyone please tell me the use cases of multiple Dispatcher-Servlets.
I think every use case can be solved by using single Dispatcher Servlet.

回答1:

As DispatcherServlet is very flexible. Not only Spring MVC uses it, but also Spring WS and etc.

In general, we declare multiple dispatcher servlets when we need multiple sets of MVC configuration. For example, we may have a REST API alongside a traditional MVC application or an unsecured and a secure section of a website:

Source of this answer, read in detail...

回答2:

Strictly seperating user and admin functionality. Or one for plain Spring MVC and another for Spring Web Flow. If there are major configuration differences for some controllers. (We actually used the Spring MVC and Spring Web Flow seperation so that we could add this without affecting the already exising configs). Nowadays with servlet 3.0 you could develop seperate parts of your application seperatly and have all of them contribute there own DispatcherServlet and mappings (although you could also achieve this with some configuration conventions).

回答3:

From Documentation

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.

Advantages of multiple dispatcher servlets ^_OR Why we need multiple dispatcher servlets? ^_OR When do 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.