Hello World Web App using Spring Annotations Part 5

In Part 5 of this series, we finally get to write some Java!  We’ll create a simple Spring controller using Annotations, using the web application requirements from part 1.

If you have missed the previous parts of this series, you can find them here: part 1, part 2, part 3, part 4.  You’ll need to setup your environment from parts 1-4 if you want to follow along with the examples here.

Creating the Spring Controller

Finally!  Let’s write some Java!

Before we do though, let’s review the requirements of our webapp from part 1:

  • Use a Spring MVC controller and a JSP page to show a simple message
  • Use Spring Annotations instead of the old MVC package
  • Minimum amount of XML configuration (in fact, it is 27 lines of XML in the end)
  • The message must come from the controller, not be hard-coded into the JSP
  • Package the web application into a WAR file (using Maven)

So, for our controller, we need to use Annotations (requirement 2), and we need a JSP page to show the message (requirement 1).  The controller must hold the message, not the JSP (requirement 3). We’ve already finished the configuration (requirement 3) in 27 lines.

So, we need a controller that has a message in it, and forwards the message to a JSP (that is, a “view” in the Spring world).  Easy.  Let’s create a new class by right-clicking on the /src/main/java folder and selecting New > Class.

NewClass

We’re are going to call our class “IndexController”, and we’ll place it in package “com.technologicaloddity.hellowebapp”.  (Note: If you are like me, you often change package names in examples. That’s OK, but if you change it here, you also need to change the component-scan piece in the dispatch-servlet.xml.  If you use the package given here, you don’t need to do anything special)

Enter “com.technologicaloddity.hellowebapp” in the Package field, and “IndexController” in the Name field.  Then click the Finish button.

NewJavaClass

Now, let’s write the controller, then go over it line-by-line:

package com.technologicaloddity.hellowebapp;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;

@Controller
public class IndexController {

    @RequestMapping(value="/index.html")
    public String handleRequest(Model model) {
        model.addAttribute("message", "Hello Web World!");
        return "index";
    }

}

Line 1: This is the standard Java package declaration.

Line 3: Import’s Spring’s Controller stereotype (see line 7)

Line 4: Import Spring’s Model object, which is combined with the view to render an end-user web page.

Line 5: Import Spring’s RequestMapping annotation, which allows us to map a URL to a Controller or method with an annotation (instead of in XML configuration, which is the way Spring 2.0 does it)

Line 7: Here’s the “stereotype” was are using.  Spring defines several stereotypes, such as @Component and @Entity.  In this case, we are using the @Controller stereotype, which provides functions needed by a web controller.  This is major part of requirement 2.

Line 8: The standard Java class definition.  If you are used to Spring 2.0, notice that this class doesn’t extend anything like AbstractController or SimpleFormController.  With the @Controller stereotype, this isn’t needed anymore.

Line 10: Here is our RequestMapping definition.  Basically, this annotation says that if the user requests index.html, this method will handle it.  All mappings are relative to the webapp context (/HelloWebApp in this case), so this annotation is a mapping for /HelloWebApp/index.html.

Line 11: The method definition.  Here we’ve decided to call it “handleRequest”.  We could have called it “bigFooBarMethod”.  The name doesn’t matter in the slightest.  It takes a Spring Model as a parameter and returns a String.  The returned String is the view name that will Spring will use to render the page (the name of the view associated with the JSP, in other words).  Note that neither the Model or the String return is required with RequestMapping.  There are several options that you can mix and match in a RequestMapping method: @RequestParameter, @PageParameter, returning a ModelAndView instead of a String, etc.  We’ve chosen Model and String return because it matches our requirements.  Returning a view name (String) fulfills requirement 3.

Line 12: Here is where our message is defined (requirement 4).  We are going to add it to the Model as name “message”.  Remember that our @Controller will use this Model and the view name we return to render the page.  Therefore, the attribute “message” will now be available to the JSP, since it is part of the Model.

Line 13: Here we return the name of the view we would like to use.  Remember from our dispatch-servlet.xml file that we prefix view names with “/WEB-INF/jsp/” and we postfix them with “.jsp”.  Therefore, since we are returning view “index”, it will look for a JSP in /WEB-INF/jsp/index.jsp (which we will create later).

Line 14 and forward: Just closing up our blocks.

In part 6, we’ll create the view from line 13, and run the whole thing on Tomcat and Sysdeo.

Leave a Reply

Your email address will not be published. Required fields are marked *