Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How does DispatcherServlet work if we have multiple XML Configuration file?

Questions

How does DispatcherServlet work if we have multiple XML Configuration file so how does Spring Application Context loads them and acts on them ?

Scenario:

In my case, we have an application that is supposed to global that is application should have AP{Asia-Pacific}, EM{Europ-Middleeast}, CA{Canada} and LA{Latin America} Versions.

Currently, we have Application for one region that is EMand its has its XML Configuration File i.e, em-servelt.xml and then there is generic web.xml file now for AP region we have another ap-servlet.xml file and by the way both em-servlet.xml and ap-servlet.xml file would have same bean names but they would be pointing to Controllers in different packages, so for example, em would be pointing to something like com.em.DomainController and ap would be pointing to com.ap.DomainController.

So my question is

How is the request mapped to different controllers and how request is being recognized so that it should read from ap-servlet.xml or em-servlet.xml ?

I hope am able to clearly state my question.

like image 335
Rachel Avatar asked Oct 29 '10 18:10

Rachel


People also ask

Can we have multiple DispatcherServlet?

Yes, a Spring MVC web application can have more than one DispatcherServlets. Each DispatcherServlet has to operate in its own namespace. It has to load its own ApplicationContext with mappings, handlers, etc. Only the root application context will be shared among these Servlets.

Which configuration is used for DispatcherServlet controller?

Requests that you want the DispatcherServlet to handle will have to be mapped using a URL mapping in the same web. xml file. This is standard J2EE servlet configuration; an example of such a DispatcherServlet declaration and mapping can be found below.

Can we have more than one dispatcher servlet in web xml?

You can configure multiple DispatcherServlet instances, each having its own configuration like en-servlet. xml, ib-servlet. xml etc.

What is DispatcherServlet How does it work?

DispatcherServlet handles an incoming HttpRequest, delegates the request, and processes that request according to the configured HandlerAdapter interfaces that have been implemented within the Spring application along with accompanying annotations specifying handlers, controller endpoints, and response objects.


2 Answers

The web.xml file can configure multiple DispatcherServlet instances, each having its own configuration. Each DispatcherServlet instance configures a WebApplicationContext separate from other DispatcherServlet instances, so you can use the same bean names without affecting the other application context.

<!-- configured by WEB-INF/ap-servlet.xml -->
<servlet>
    <servlet-name>ap</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

<!-- configured by WEB-INF/em-servlet.xml -->
<servlet>
    <servlet-name>em</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

You must also configure web.xml to map requests to the appropriate DispatcherServlet. For example, each region could have a different URL path.

<servlet-mapping>
    <servlet-name>ap</servlet-name>
    <url-pattern>/ap/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>em</servlet-name>
    <url-pattern>/em/*</url-pattern>
</servlet-mapping>
like image 78
Chin Huang Avatar answered Sep 25 '22 11:09

Chin Huang


The web.xml file controls which context file DispatcherServlet is using. If you configure web.xml to have a DispatcherServlet with name em, then by default it uses em-servlet.xml to load the web context.

Your question is a bit confusing as to what you would actually like to do - do you want all "versions" to be available in the same instance of the application?

If so, the method you describe sounds unorthodox for how to present multiple languages / globalizing your application. Traditionally you would just have a single instance of the application and all the controllers/instances, and then handle translating user-visible messages at the display level. Spring has excellent support for this.

If your goal is to have a single instance of the application serve requests for all these languages/locales, then it sounds like you could do away with a lot of this redundancy.

like image 42
matt b Avatar answered Sep 23 '22 11:09

matt b