The DispatcherServlet - Java-Springs

Spring's web MVC framework is, like many other web MVC frameworks, request-driven, designed around a central servlet that dispatches requests to controllers and offers other functionality that facilitates the development of web applications. Spring's Dispatcher Servlet however, does more than just that. It is completely integrated with the Spring IoC container and as such allows you to use every other feature that Spring has.

The request processing work flow of the Spring Web MVC Dispatcher Servlet is illustrated in the following diagram. The pattern-savvy reader will recognize that the Dispatcher Servlet is an expression of the “Front Controller” design pattern (this is a pattern that Spring Web MVC shares with many other leading web frame works).

Figure:-

processing-workflow-in-Spring-Web-MVC

The requesting processing workflow in Spring Web MVC (high level) The Dispatcher Servlet is an actual Servlet (it inherits from the Http Servlet base class), and as such is declared in the web.xml of your web application. You need to map requests that you want the Dispatcher Servlet to handle, by using a URL mapping in the same web.xml file.This is standard J2EE servlet configuration; the following example shows such a Dispatcher Servlet declaration and mapping:

<web-app>
<servlet>
<servlet-name>example</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>example</servlet-name>
<url-pattern>*.form</url-pattern>
</servlet-mapping>
</web-app>

In the preceding example, all requests ending with .form will be handled by the example Dispatcher Servlet.This is only the first step in setting up Spring Web MVC. You now need to configure the various beans used by the Spring Web MVC frame work (over and above the Dispatcher Servlet itself).

In the Web MVC frame work, each Dispatcher Servlet has its own Web Application Context, which inherits all the beans already defined in the root Web Application Context. These inherited beans can be overridden in the servlet-specific scope, and you can define new scope-specific beans local to a given servlet instance.

Context hierarchy in Spring Web MVC:-

Context hierarchy in Spring Web MVC

Upon initialization of a DispatcherServlet, the frame work looks for a file named [servlet-name]-servlet.xml in the WEB-INF directory of your web application and creates the beans defined there, overriding the definitions of any beans defined with the same name in the global scope.

Consider the following DispatcherServlet servlet configuration (in the web.xml file):

<web-app>
<servlet>
<servlet-name>golfing</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>golfing</servlet-name>
<url-pattern>/golfing/*</url-pattern>
</servlet-mapping>
</web-app>

With the above servlet configuration in place, you will need to have a file called /WEB-INF/golfing-servlet.xml in your application; this file will contain all of your Spring Web MVC-specific components (beans). You can change the exact location of this configuration file through a servlet initialization parameter.

The Web Application Context is an extension of the plain Application Context that has some extra features necessary for web applications.It differs from a normal Application Context in that it is capable of resolving themes, and that it knows which servlet it is associated with (by having a link to the Servlet Context).The Web Application Context is bound in the ServletContext, and by using static methods on the RequestContextUtils class you can always look up the Web Application Context if you need access to it.

The Spring Dispatcher Servlet uses special beans to process requests and render the appropriate views. These beans are part of Spring Frame work. You can configure them in the Web Application Context, just as you configure any other bean. However, for most beans, sensible defaults are provided so you initially do not need to configure them. These beans are described in the following table.

Table: Special beans in the WebApplicationContext

Special beans in the Web Application ContextSpecial beans in the Web Application Context

After you set up a DispatcherServlet, and a request comes in for that specific DispatcherServlet, the DispatcherServlet starts processing the request as follows:

  1. The Web Application Context is searched for and bound in the request as an attribute that the controller and other elements in the process can use. It is bound by default under the key Dispatcher Servlet. WEB_APPLICATION_CONTEXT_ATTRIBUTE.
  2. The locale resolver is bound to the request to enable elements in the process to resolve the locale to use when processing the request (rendering the view, preparing data, and so on). If you do not need locale resolving, you do not need it.
  3. The theme resolver is bound to the request to let elements such as views determine which theme to use. If you do not use themes, you can ignore it.
  4. If you specify a multipart file resolver, the request is inspected for multiparts; if multiparts are found, the request is wrapped in a Multi part Http Servlet Request for further processing by other elements in the process.
  5. An appropriate handler is searched for. If a handler is found, the execution chain associated with the handler (pre processors, post processors, and controllers) is executed in order to prepare a model or rendering.
  6. If a model is returned, the view is rendered. If no model is returned, (may be due to a preprocessor or postprocessor intercepting the request, perhaps for security reasons), no view is rendered, because the request could already have been fulfilled.

Handler exception resolvers that are declared in the WebA pplication Context pick up exceptions that are thrown during processing of the request.Using these exception resolvers allows you to define custom behaviors to address exceptions.

The Spring Dis patcher Servlet also supports the return of the last-modification-date, as specified by the Servlet API. The process of determining the last modification date for a specific request is straight forward:the Dispatcher Servlet looks up an appropriate handler mapping and tests whether the handler that is found implements the Last Modified interface. If so, the value of the long get Last Modified(request) method of the Last Modified interface is returned to the client.

You can customize individual Dispatcher Servlet instances by adding servlet initialization parameters (init-param elements) to the servlet declaration in the web.xml file. See the following table for the list of supported parameters.

Table DispatcherServlet initialization parameters

DispatcherServlet initialization parameters


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Java-Springs Topics