Section 2.1. Setting Up Tomcat | Spring: A Developers Notebook

2.1. Setting Up Tomcat

In this first example, you'll learn how to build a simple user interface with Tomcat with Spring's Web MVC framework. You'll add a couple of screens to add bikes to the inventory of rental bikes. Then, we'll add a hardwired JSP that will let you add a new bike to the database.

Note: Spring doesn't force you to use a full application server. Actually, you don't even have to build web-based applications. The requirement for Tomcat is really a requirement for some servlet container, purely because this application (not Spring) requires it.

Spring doesn't give you a servlet container. Instead, it just gives you a set of services that make it easier to build web applications.

Most projects simply don't need a full-blown J2EE container. One of the best things about Spring is that you can deploy it, in production, without paying for an application server, or the hardware that you'd need to run one. Tomcat will manage your servlets, provide an easy architecture for managing deployments, and let you manage its threading model.

2.1.1. How do I do that?

First, you'll go to http://jakarta.apache.org/tomcat. There, you'll find Apache Tomcat 5.0.27, which is the version that we're using for all of our examples. If you want to use something else, that's okay. You'll just need some type of servlet container that supports:

JSP Version 1.2 or higher
Servlet Version 2.3 or higher

Next, you'll modify the façade to the RentABike, so that you can do simple create/read/update/delete (CRUD) methods. Example 2-1 gives the new façade.

Example 2-1. RentABike.java

public interface RentABike {     List getBikes( );     Bike getBike(String serialNo);      void saveBike(Bike bike);     void deleteBike(Bike bike);     void setStoreName(String name);     String getStoreName( ); }

And you'll want to access that through a simple user interface. For now, you'll hardwire the façade to a simple JSP. We'll do one simple JSP right now, that outputs a list of all the bikes in the store (Example 2-2). Notice that from here on out, we've moved our code into a package, com.springbook. The source files for the domain classes should move into the src\com\springbook folder as well. Here's the hardwired JSP.

Note: Here's the interface for the RentABike façade. You'll later see this injected with Spring.

Example 2-2. Listbikes.jsp

<%@ page import="com.springbook.*"%> <% RentABike store = new ArrayListRentABike                      ("Bruce's  Bikes"); %> <html>    <head>       <title>          <%= store.getStoreName( ) %>       </title>    </head>    <body>       <h1><%= store.getStoreName( ) %></h1>       <table border="1" cellspacing="2" cellpadding="2">          <tr style="font-weight:bold">             <td>Manufacturer</td><td>Model</td><td>Status</td>          </tr>          <% for(int i=0;i<store.getBikes( ).size( );i++) { %>             <% Bike bike = (Bike)store.getBikes( ).get(i); %>             <tr>                <td><%= bike.getManufacturer( ) %></td>                <td><%= bike.getModel( ) %></td>                <td><%= bike.getStatus( ) %></td>             </tr>          <% } %>       </table>    </body> </html>

Next, you'll want to configure the application. With J2EE servlets, that happens in the web.xml file. At this point, the web.xml file is simplicity itself. In fact, you could even leave it out for now, but for the sake of completeness, go ahead and add it. Example 2-3 shows the web.xml, which you'll put in a directory called war/WEB-INF, off of your main project directory.

Example 2-3. web.xml

<!DOCTYPE web-app    PUBLIC  "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"    "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> <web-app> </web-app>

You'll need to change Ant's build.xml to add a deploy step. This step packages everything that Tomcat will need to run your application, including JSPs, Java classes, the servlet configuration in web.xml, and the Spring context. Example 2-4 gives the additions to the Ant script.

Example 2-4. build.xml

<property name="webapp.dir" value="C:/tomcat/webapps/bikestore"/> <target name="deploy" depends="compile"         description="Copies the contents of web-app to destination dir">    <copy todir="${webapp.dir}">       <fileset dir="${war.dir}"/>    </copy> </target>

Finally, you'll build and deploy, as in Example 2-5.

Example 2-5. Output from running Ant on build.xml

buildfile: build.xml init:     [mkdir] Created dir: C:\RentABikeApp\war\WEB-INF\classes     [mkdir] Created dir: C:\RentABikeApp\test\classes compile:     [javac] Compiling 9 source files to C:\RentABikeApp\war\WEB-INF\classes deploy:      [copy] Copying 9 files to C:\@Tools\Apache Software Foundation\Tomcat  5.0\webapps\bikestore BUILD SUCCESSFUL Total time: 2 seconds

2.1.2. What just happened?

You just walked through the build and deploy cycle for Tomcat, which is:

Write the code for your application.
Configure it through web.xml
Package it in a .war file

Note: Actually, the package step at this point is optional. You don't have to build a war; you can leave the files exploded. Most developers will eventually choose to do so.

Deploy it in Tomcat
Run it

The browser makes a request to Tomcat, which then routes the request to a JSP. The first time that you run the application, Tomcat compiles the JSP into a servlet, and executes it. The JSP returns a result in the form of HTML, via HTTP, to the browser.

Of course, most J2EE applications have long since moved on to architectures like EJB that require much more than Tomcat. That's unfortunate, because many applications run just fine in a basic servlet container.

In fact, I've seen a resurgence of applications that put the full J2EE on the back burner, and choose to run simple containers. In my classes, I regularly ask how many people are using EJB, a full J2EE server without EJB, or a servlet container. The numbers of people choosing Tomcat, or something similar, is growing rapidly. Everything old is new again.