MemeStorm

You want to get started with a simple web application that utilizes Spring’s web MVC framework. Here’s a simple project that provides such a start. It doesn’t use all of Spring’s features, nor even the best, but it will serve as a discussion point for future blog entries.

Background

When you’re putting together a simple web application, you need a few essentials:

• A dispatcher servlet, which will intercept incoming requests.
• A configuration that instructs the web container to route requests to the dispatcher servlet (ie. a servlet mapping)
• Controllers (the C in MVC) that can perform the business logic and route to particular views (the V) perhaps conveying information models (the M).
• A way for the dispatcher servlet to know which URLs to map to which controllers - called a url mapping
• A way to determine, when a controller has done its job, how to get to the view - called a view resolver

The simple application here, skeleton1, doesn’t have a model at all, has a single controller (web.DispatchController), and a single view (myview.jsp)

How to do it and How it works

Download the source for the details. First, we want to use Spring’s DispatcherServlet as the entry point to our web application. You configure this simply in your web.xml:

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

Get it? This says: Create the servlet for me, call it dispatch, and map all incoming URLs that start with send to the dispatch servlet. So for example, a URL such as http://.../skeleton1/send/foobar would activate the dispatch servlet.

The rest of the configuration you do in a Spring web application context. Spring automatically looks for it using the name of the servlet as a hint. Since our servlet is called dispatch, it looks for a file called dispatch-servlet.xml in your WEB-INF directory. This configuration file will have three bits to it: the controller(s), the url mapping and the view resolver. First, the controller:

<bean id="dispatchController"
class="com.memestorm.web.DispatchController">
</bean>

No rocket science there. It’s simply a bean implementing the appropriate interface, which we’ll look at later.

The view resolver tells us how to render the output from a controller. Here’s the one I chose:

<bean id="viewResolver"
class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="prefix">
<value>/WEB-INF/views/</value>
</property>
<property name="suffix">
<value>.jsp</value>
</property>
</bean>

This uses a Spring-implemented InternalResourceViewResolver which basically maps to like-named views in the /WEB-INF/views directory, adding a .jsp. So for example, if our controller said “Please go to view myview,” then the above resolver would try to find the file myview.jsp in /WEB-INF/views. This is easy and extensible.

The final configuration is the URL mapping, which essentially tells the dispatcher servlet how to behave: Which incoming requests should it map to which controllers? We’ve chickened out:

<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<props>
<prop key="/*">dispatchController</prop>
</props>
</property>
</bean>

This again uses a Spring-supplied URL mapper (isn’t it great, you don’t have to write any code) which, as you can see, maps all requests (/*) to the controller called dispatchController (which we defined above).

The last key to the puzzle is the controller itself. We know now that appropriate URLs (that are mapped to our dispatcher servlet) will be intercepted by the dispatcher servlet. It will then look at the URL, and on the basis of the URL mapper, map it to a particular controller (in this case, it maps all incoming URLs to the same controller), and to do this operationally it needs to invoke a method on the controller. Which method? Well, this particular URL mapper looks at the URL and “lops off” the start bit and uses what’s left. For example, if you went to http:.../skeleton1/send/actionName then it will try to invoke the method actionName() on dispatchController. Nothing too it. So, let’s check out the controller!

public class DispatchController extends MultiActionController {

public ModelAndView actionName(HttpServletRequest request,
HttpServletResponse response) throws Exception {
ModelAndView mav = new ModelAndView("myview");
mav.addObject("message", "Hiya");
return mav;
}
}

Pretty simple. This class implements the Spring MultiActionController (which really means we can have multiple control methods defined here), and provides a single control action method called actionName(). Check out the parameters - pretty much like a servlet which isn’t too surprising. The result is: ModelAndView. This is really a wrapper that tells Spring what the model data is (what data do you want to send to your view) and which view to actually send it to. In this case, we want to go to the view myview and send a string along too.

If you’ve been paying attention, you’ll know that our view resolver will look for myview.jsp, and yes, that’s what we have. Here’s a look at it:

Hello, you're in myview.jsp! <br />
The controller sent me some data,
here it is: <%=request.getAttribute("message") %>

Nothing too it. It prints a message, and grabs the model from the appropriately named attribute in the request.

So, if we now invoked http://../skeleton1/send/actionName our action will get invoked, which will eventually forward to this JSP page. You can extend at will, adding additional action methods for example, additional controllers if you like, and of course, additional views.

Downloading

Download the source
skeleton1.zip
and read the installation instructions. Short version: Download Spring (with dependencies, I’m using Spring 2M2), modify one property in our build file to point to the unzipped Spring distribution, run the build with ant, deploy on a web container (I use Tomcat).

Advanced

You’ll note that the code does just a little more than described above. In particular, we create an additional root application context with two beans a,b, and we make sure that we access and call these beans from the controller. Oh, and we use the logging described in Refreshable log4j configuration files.