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:
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.
| 
No comments:
Post a Comment