Spring: In a Nutshell

Configure web.xml so that the servlet container passes incoming httpServletRequests to Spring’s DispatcherServlet.



Configure web.xml so that the DispatcherServlet knows where to find the WebApplicationContext. The default ContextLoaderListener will look for an applicationContext.xml file and a {servlet-name}-servlet.xml file. This split enables you to keep web-specific beans outside of the main applicationContext, and also, because it is set up as a child of the main context, to refer to parent service objects in the web context.


The DispatcherServlet, which you should not have to modify, uses the WebApplicationContext to model the workflow of the request.

context object function
HandlerMapping decides which controller should handle a request
Controller / Handler handles request
ViewResolver decides which View a String name represents
MultiPartResolver (for file uploads)
ThemeResolver (for different style sheets / resource bundles)
HandlerExceptionResolver (behaviour when handler throws exception)
HandlerInterceptor (pre- or post-processing of requests)

In the simplest case, only the first three items in the table are used.

Based on the HandlerMapping, the DispatcherServlet passes the incoming to request to one of the controllers. There are various implementations; the simplest is to add a name attribute to the controller bean definition, thus:

<bean id="findUserFormController" name="/findUser.html"

The controller implements

interface Controller {
    ModelAndView handleRequest(request, response);

and returns a ModelAndView object. The ModelAndView consists of a model, a Map holding the data to be put into the response, and a reference to a View, which implements

interface View {
    void render(model, request, response);

and actually renders the response to the client, usually by evaluating a template (eg jsp page) and plugging the model data into it.

Since a ModelAndView will usually contain just a reference to (String name of) a View and not the View itself, a ViewResolver may have to be consulted to discover the actual View. This can be as simple as an InternalResourceViewResolver, which just gives the type of view and the prefix and suffix of where the template file can be found (eg, given View reference “findUserByName”, locate it at “/WEB-INF/pages/findUserByName.jsp”, and fill it in using JSTL).

<bean id="viewResolver"
    <property name="viewClass"
    <property name="prefix" value="/WEB-INF/pages/"/>
    <property name="suffix" value=".jsp"/>

(Getting this to work with our new html rendering engine would involve creating a new View and implementing render with something like what our current BaseViewAction does, getting the content from the Model instead of the ContentProviders.)

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply