Core Servlets & JSP 2/E
More Servlets & JSP
| Configuring & Using Apache Tomcat |
|---|
| Contents |
|---|
| Introduction |
|---|
|
Core Servlets & JSP 2/E |
|---|
|
More Servlets & JSP |
Integrating Tomcat as a plugin within the regular Apache server or a commercial Web server (for deployment) is more complicated that what is described here. Although such integration is valuable for a deployment scenario (see http://jakarta.apache.org/tomcat/tomcat-5.0-doc/), my goal here is to show how to use Tomcat as a development server on your desktop. Regardless of what deployment server you use, you'll want a standalone server on your desktop to use for development.
The examples here assume you are using Windows, but they can be easily adapted for Solaris, Linux, and other versions of Unix. I've gotten many reports of successful use on MacOS X, but don't know the setup details. Except when I refer to specific Windows paths (e.g., C:\blah\blah), I use URL-style forward slashes for path separators (e.g., install_dir/webapps/ROOT). Adapt as necessary.
The information here is adapted from the introductory setup and configuration
chapter of Core Servlets and JavaServer Pages, 2nd Edition, Volume 1
from Sun Microsystems Press and Prentice Hall. For the book table of contents, index,
source code, etc., please
see http://volume1.coreservlets.com/.
For information on servlets, JSP, Apache Struts, JSF, and Java training courses (either at public
venues or on-site at your company) taught by the author of the book
and this Tomcat tutorial, please see
http://courses.coreservlets.com.
To report errors or omissions in this writeup or to inquire about
on-site training courses on servlets/JSP/Struts/JSF/Java, please contact Marty Hall
at hall@coreservlets.com.
| Executive Summary |
|---|
| JSP, Servlet, Struts, & JSF Training |
|---|
|
Looking for hands-on training? Tired of inexperienced
instructors teaching someone else's course materials?
Want a choice of public or onsite courses? Check out
courses.coreservlets.com.
Distinctive features:
|
PATH is set so that both "java -version" and
"javac -help" give a result.
JAVA_HOME variable.
Set it to refer to the base JDK directory, not the bin subdirectory.
<Context path="" docBase="ROOT" debug="0"/>.
Not necessary in Tomcat 4.0.3 and earlier. In most versions of
Tomcat 5, the element is missing the trailing slash and you need to add it.
<DefaultContext reloadable="true"/>
port attribute of the Connector
element from 8080 to 80.
servlet and
servlet-mapping elements that map the invoker
servlet to /servlet/*. In Tomcat 4, you only need to uncomment the
servlet-mapping element, and this is not necessary
at all prior to Tomcat 4.1.12.
CATALINA_HOME variable.
Optionally, set CATALINA_HOME to refer to the top-level
Tomcat installation directory. Not necessary unless you copy the
startup scripts instead of making shortcuts to them.
CLASSPATH.
Include the current directory ("."), the servlet/JSP JAR file(s)
(install_dir/common/lib/servlet.jar for Tomcat 4,
install_dir/common/lib/servlet-api.jar and
install_dir/common/lib/jsp-api.jar for Tomcat 5)
and your main development directory from Step 1.
CLASSPATH
includes the top level of your development directory.
-d option of javac.
Use -d to tell Java where the deployment directory is.
ant or a similar tool.
Use the Apache make-like tool to automate copying of files.
| Install the JDK |
|---|
Your first step is to download and install Java. The servlet 2.3 specification (JSP 1.2) requires JDK 1.2 or later; the servlet 2.4 spec (JSP 2.0) requires JDK 1.3 or later; J2EE 1.4 (which includes servlets 2.4 and JSP 2.0) requires JDK 1.4 or later. I recommend you simply get the latest Java version: JDK 1.4. See the following sites for download and installation information.
PATH is configured properly by opening a DOS
window and typing "java -version" and "javac -help".
You should see a real result both times, not an error message about
an unknown command. Or, if
you use an IDE, compile and run a simple program to confirm that
the IDE knows where you installed Java.
| Configure Tomcat |
|---|
| JSP, Servlet, Struts, & JSF Training |
|---|
|
Looking for hands-on training? Tired of inexperienced
instructors teaching someone else's course materials?
Want a choice of public or onsite courses? Check out
courses.coreservlets.com.
Distinctive features:
|
JAVA_HOME variable.
CATALINA_HOME variable.
(Optional)
Alternatively, you can use my preconfigured Tomcat versions. These versions already have the port changed to 80, servlet reloading enabled, and the invoker servlet turned on. The preconfigured versions also come with a sample development directory and autoexec.bat file.
JAVA_HOME Variable
Next, you must set the JAVA_HOME environment variable to tell Tomcat
where to find Java. Failing
to properly set this variable prevents Tomcat from handling JSP pages.
This variable should list the base JDK installation directory,
not the bin subdirectory. For example, if you are
on Windows 98/Me and installed the JDK in C:\j2sdk1.4.2_05
on your C drive,
you might put the following line in your C:\autoexec.bat file.
set JAVA_HOME=C:\j2sdk1.4.2_05On Windows XP, you could also go to the Start menu, select Control Panel, choose System, click on the Advanced tab, press the Environment Variables button at the bottom, and enter the
JAVA_HOME
variable and value directly. On
Windows 2000 and NT, you do Start, Settings, Control Panel, System,
then Environment. If you prefer, you can use C:\autoexec.bat
on those versions of Windows also (unless a system administrator has set your PC
to ignore it).
<Context path="" docBase="ROOT" debug="0"/>Note that in most early versions of Tomcat 5, the commented out entry distributed with Apache Tomcat is in error: it is missing the trailing slash (i.e.,
<Context ... debug="0" > instead
of the proper <Context ... debug="0" />).
So, you will need to insert the slash. You can also:
To turn on servlet reloading, edit
install_dir/conf/server.xml and
add a DefaultContext subelement to the main
Host (Tomcat 5.0.20 and later) or Service (Tomcat 5.0.19 and earlier) element
and supply true for the reloadable attribute.
For example, in Tomcat 5.0.27, search for this entry:
<Host name="localhost" debug="0" appBase="webapps"
...>
and then insert the following immediately below it:
<DefaultContext reloadable="true"/>
Be sure to make a backup copy of server.xml before making
the above change. You can also:
To change the port, edit install_dir/conf/server.xml and
change the port attribute of the Connector
element from 8080 to 80, yielding a result similar to that below. Note that the exact
form of the Connector element varies in different Tomcat versions. Just
search for a non-comment occurrence of "8080".
<Connector port="80" ...
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
...
... />
You can also:
To enable the invoker servlet, uncomment the following
servlet and servlet-mapping
elements in install_dir/conf/web.xml. Note that the filename
is web.xml, not server.xml as
in the previous bullets. Also, do not
confuse this Apache Tomcat-specific web.xml file with the
standard one that goes in the WEB-INF
directory of each Web application. Finally, remember to make a backup
copy of the original version of this file before you make the changes.
<servlet>
<servlet-name>invoker</servlet-name>
<servlet-class>
org.apache.catalina.servlets.InvokerServlet
</servlet-class>
...
</servlet>
...
<servlet-mapping>
<servlet-name>invoker</servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
You can also:
CATALINA_HOME Variable (Optional)CATALINA_HOME
environment variable to refer to the top-level directory of the Apache Tomcat
installation (e.g., C:\jakarta-tomcat-5.0.27).
This variable identifies the Tomcat
installation directory to the server. However, if you are careful to avoid copying the
server startup scripts and you use only shortcuts (called "symbolic links" on
Unix/Linux) instead, you are not required to set this variable.
I recommend using shortcuts and not bothering with CATALINA_HOME.
JAVA_HOME for you. The installer hunts for your
Java installation and tries to set JAVA_HOME appropriately.
This is a convenience, albeit a minor one.
| Test the Server |
|---|
| JSP, Servlet, Struts, & JSF Training |
|---|
|
Looking for hands-on training? Tired of inexperienced
instructors teaching someone else's course materials?
Want a choice of public or onsite courses? Check out
courses.coreservlets.com.
Distinctive features:
|
If this does not work, there are a couple of things to check:
catalina run" to start Tomcat without popping up
a new window. Now, the error messages should help you figure out the
problem (e.g., JAVA_HOME not set properly or IIS already
reserving port 80).
To halt the server, double click on install_dir/bin/shutdown.bat. I recommend that you make shortcuts to (not copies of) the startup and shutdown scripts and place those shortcuts on the desktop or in your main development directory.
Eventually, you will almost certainly want to create and use your own Web applications (see Section 2.11 of the book), but for initial testing many people prefer to use the default Web application. With Tomcat and the default Web application, you put HTML and JSP pages in install_dir/webapps/ROOT or install_dir/webapps/ROOT/somePath and access them with http://localhost/filename or http://localhost/somePath/filename. Note that some Tomcat versions create install_dir/webapps/ROOT only when the server is first run. So, you must start the server as described above before trying to access the directory.
For your first tests, I suggest you simply take Hello.html and Hello.jsp and drop them into the appropriate locations. Right click on the links to download these two files to your system. If you download the files using Internet Explorer, just be careful that it does not try to change the file extension, yielding Hello.htm instead of Hello.html. The code for these files, as well as all the code from the book, is available online at http://volume1.coreservlets.com. That Web site also contains book updates, additions, information on servlet and JSP short courses, and the full text of the first edition of Core Servlets and JavaServer Pages (in PDF).
If you put the files in the top-level directory of the default Web application (i.e., in install_dir/webapps/ROOT), access them with the URLs http://localhost/Hello.html and http://localhost/Hello.jsp, respectively. If you put them in a subdirectory of install_dir/webapps/ROOT, use the URLs http://localhost/directoryName/Hello.html and http://localhost/directoryName/Hello.jsp, respectively.
If you successfully started the server as
described above, but
neither the HTML file nor the JSP file works (e.g., you get File Not
Found--404--errors), you likely are using the wrong directory for the files or
you forgot to enable the ROOT context. If the
HTML file works but the JSP file fails, you probably have incorrectly specified the
base JDK directory (i.e., with the JAVA_HOME variable).
| Set Up Your Development Environment |
|---|
The server startup script automatically sets the
server's CLASSPATH to include the
standard servlet and JSP classes and the
WEB-INF/classes directory (containing
compiled servlets) of each Web application. But you
need similar settings, or you will
be unable to compile servlets in the first place.
Configuring your system for servlet development involves
the following four steps:
CLASSPATH
Eventually, you will organize this development directory into different Web applications (each with a common structure--see Section 2.11 of the book for details). For initial testing of your environment, however, you can just put servlets either directly in the development directory (for packageless servlets) or in a subdirectory that matches the servlet package name. Many developers simply put all their code in the server's deployment directory (within install_dir/webapps). I strongly discourage this practice and instead recommend one of the approaches described in the deployment section. Although developing in the deployment directory seems simpler at the beginning since it requires no copying of files, it significantly complicates matters in the long run. Mixing locations makes it hard to separate an operational version from a version you are testing, makes it difficult to test on multiple servers, and makes organization much more complicated. Besides, your desktop is almost certainly not the final deployment server, so you'll eventually have to develop a good system for deploying anyhow.
For example, one way to make these shortcuts is to go to
install_dir/bin, right-click on startup.bat,
and select Copy. Then go to your development directory, right-click in the
window, and select Paste Shortcut (not just Paste). Repeat the process for
install_dir/bin/shutdown.bat. If you put the shortcuts on your desktop,
you can also assign keyboard shortcuts to invoke them. On Unix, you would use
ln -s to make a symbolic link
to startup.sh, catalina.sh
(needed even though you don't directly invoke this file), and
shutdown.sh.
CLASSPATHjavac)
you use for development probably
doesn't. So, if you don't set your CLASSPATH,
attempts to compile servlets, tag libraries,
or other classes that use the servlet and JSP APIs will fail with error messages about
unknown classes. Here are the standard Tomcat locations:
CLASSPATH).
Now, in addition to the servlet JAR file, you also need to put your development
directory in the CLASSPATH. Although this is
not necessary for simple packageless
servlets, once you gain experience you will almost certainly use packages. Compiling
a file that is in a package and that uses another class in the same package requires the
CLASSPATH to include the directory that is at the
top of the package hierarchy. In
this case, that's the development directory I just discussed.
Forgetting this setting is perhaps the most common
mistake made by beginning servlet programmers!
Finally, you should include "." (the current directory)
in the CLASSPATH. Otherwise,
you will only be able to compile packageless classes that are in the top-level
development directory.
Here are two representative methods of setting the
CLASSPATH. They assume
that your development directory is C:\Servlets+JSP.
Replace install_dir with the actual base installation
location of the server. Also, be sure to use the appropriate
case for the filenames, and enclose your pathnames in double
quotes if they contain spaces.
set CLASSPATH=.;
C:\Servlets+JSP;
install_dir\common\lib\servlet.jar
set CLASSPATH=.;
C:\Servlets+JSP;
install_dir\common\lib\servlet-api.jar;
install_dir\common\lib\jsp-api.jar
CLASSPATH. Many
Java integrated development environments have a global or project-specific setting
that accomplishes the same result. But these settings are totally IDE-specific and
won't be discussed here. Another alternative is to make a script whereby
-classpath ... is automatically appended onto calls to javac.
CLASSPATH value from the previous bullet.
javax.servlet packages.
You can access the documentation from the Tomcat home page, but you probably will want access to the API even when the server is not running. So, I recommend you open the top-level file directly from disk and bookmark that location. Here are the standard locations:
| Compile and Test Some Simple Servlets |
|---|
OK, so your environment is all set. At least you think it is. It would be nice to confirm that hypothesis. Verifying this involves the following three steps:
| What about install_dir/shared/classes? |
|---|
|
"Hey, wait! Shouldn't I use install_dir/shared/classes
instead of install_dir/webapps/ROOT/WEB-INF/classes?"
Nope. There are two reasons why it is preferable to use install_dir/webapps/ROOT/WEB-INF/classes: 1. It is standard. The ROOT directory follows the normal structure of a Web application (see Section 2.11 of the book): HTML/JSP files go in the main directory, the web.xml file goes in WEB-INF, unjarred Java classes go in WEB-INF/classes, and JAR files go in WEB-INF/lib. So, if you use WEB-INF/classes, you are using a structure that works on all servers that support servlets 2.2 and later. On the other hand, install_dir/shared/classes is a Tomcat-specific location that is supported on few, if any, other servers. 2. It is specific to a Web application. Once you become comfortable with the basics, you will almost certainly divide your projects up into separate Web applications. By putting your code in WEB-INF/classes, you are ready for this, since your code is already part of a Web application (the default one for Tomcat). So, the code can easily move to another Web application, and it will not interfere with any future applications. On the other hand, install_dir/shared/classes results in code that is shared by all Web applications on your server. This is almost never what you want for servlets. |
CLASSPATH settings (see the earlier section
on this topic)--you most likely erred in listing the location of the
JAR file that contains the servlet classes
(e.g., install_dir/common/lib/servlet.jar for Tomcat 4).
Once you compile HelloServlet.java, put HelloServlet.class
in install_dir/webapps/ROOT/WEB-INF/classes. After compiling the code,
access the servlet with the URL
http://localhost/servlet/HelloServlet
(or http://localhost:8080/servlet/HelloServlet if you
chose not to change the port number as
described earlier). You should get
a simple HTML page that says "Hello".
If this URL failed but the test of the server itself
succeeded, you probably put the class file in the wrong directory
or forgot to enable the invoker servlet.
coreservlets package, it should go
in the coreservlets directory
both during development and when deployed to the server.
Once you compile HelloServlet2.java, put HelloServlet2.class in
install_dir/webapps/ROOT/WEB-INF/classes/coreservlets.
For now, you can simply copy (not move!) the coreservlets subdirectory
from the development directory to install_dir/webapps/ROOT/WEB-INF/classes.
An upcoming section
will provide some other options for the deployment process.
Once you have placed the servlet in the proper directory, access it with the URL http://localhost/servlet/coreservlets.HelloServlet2. You should get a simple HTML page that says "Hello (2)". If the first test succeeded but this test failed, you probably either typed the URL wrong (e.g., used a slash instead of a dot after the package name) or put HelloServlet2.class in the wrong location (e.g., directly in install_dir/webapps/ROOT/WEB-INF/classes directory instead of in the coreservlets subdirectory).
coreservlets package that uses
the
ServletUtilities class to simplify the generation of the
DOCTYPE (specifies the HTML version--useful
when using HTML validators) and HEAD
(specifies the title) portions of the
HTML page. Those two parts of the page are useful (technically required, in fact),
but are tedious to generate with servlet println statements.
Since both the servlet and the utility class are in
the coreservlets package,
they should go in the coreservlets directory.
If you get compilation errors such as "Unresolved symbol: ServletUtilities",
check the following two things.
CLASSPATH must include the top-level directory
of your package hierarchy before you can compile a packaged class that makes use
of another class from the same package. This requirement is not particular to servlets;
it is the way packages work on the Java platform in general. Nevertheless,
many servlet developers are unaware of this fact, and it is one of the (perhaps the) most
common errors beginning developers encounter.
Once you compile HelloServlet3.java (which will automatically cause ServletUtilities.java to be compiled), copy (don't move!) the entire coreservlets subdirectory from your development location to install_dir/webapps/ROOT/WEB-INF/classes. Then, access the servlet with the URL http://localhost/servlet/coreservlets.HelloServlet3 (again, note that it is a dot, not a slash, between the package name and the servlet name). You should get a simple HTML page that says "Hello (3)".
| Establish a Simplified Deployment Method |
|---|
OK, so you have a development directory. You can compile servlets with or without packages. You know which directory the servlet classes belong in. You know the URL that should be used to access them. (Actually, http://hostname/servlet/ServletName is just the default URL; you can also use the web.xml file to customize that URL; for details, see Section 2.11 of the book.) But how do you move the class files from the development directory to the deployment directory? Copying each one by hand every time is tedious and error prone. Once you start using Web applications, copying individual files becomes even more cumbersome.
There are several options to simplify the process. Here are a few of the most popular ones. If you are just beginning with servlets and JSP, you probably want to start with the first option and use it until you become comfortable with the development process. Note that I do not list the option of putting your code directly in the server's deployment directory. Although this is one of the most common choices among beginners, it scales so poorly to advanced tasks that I recommend you steer clear of it from the start.
-d option of javac.
ant or a similar tool.
ln -s) in a manner similar to that for Windows shortcuts.
An advantage of this approach is that it is simple. So, it is good for beginners who want to concentrate on learning servlets and JSP, not deployment tools. Another advantage is that a variation applies once you start using your own Web applications. (See Chapters 4-6 of More Servlets and JSP for details on Web applications). For instance, with Tomcat, you can easily make your own Web application by putting a copy of the install_dir/webapps/ROOT directory into your development directory and renaming it (for example, to testApp). Now, to deploy your Web application, just make a shortcut to install_dir/webapps and copy the entire Web application directory (e.g., testApp) each time by using the right mouse to drag the directory that contains your Web application onto this shortcut and selecting Copy (say Yes when asked if you want to replace existing files). Almost everything stays the same as it was without Web applications: just add the name of the directory to the URL after the hostname (e.g., replace http://localhost/blah/blah with http:/localhost/testApp/blah/blah). Just note that you'll have to restart the server the very first time you deploy the directory into install_dir/webapps.
One disadvantage of this approach is that it requires repeated copying if you use multiple servers. For example, I usually have Apache Tomcat, Macromedia JRun, and Caucho Resin on my desktop system and regularly test my code with all three servers. A second disadvantage is that this approach copies both the Java source code files and the class files to the server, whereas only the class files are needed. This does not matter on your desktop development server, but when you get to the "real" deployment server, you won't want to include the source code files.
-d Option of javacjavac) places
class files in the same directory as the
source code files from which they came. However,
javac has an option (-d) that lets
you designate a different location for the class files. You need only specify the
top-level directory for class files--javac will
automatically put packaged classes in
subdirectories that match the package names. So, for example,
I could compile the HelloServlet2 servlet as follows (line break
added only for clarity; omit it in real life).
javac -d install_dir/webapps/ROOT/WEB-INF/classes
HelloServlet2.java
You could even make a Windows batch file or Unix shell script or alias that makes
a command like servletc expand to
javac -d install_dir/.../classes.
See
http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javac.html for more details on
-d and other javac options.
An advantage of this approach is that it requires no manual copying of class files.
Furthermore, the exact same command can be used for classes in different packages
since javac automatically puts the class files in
subdirectories matching the package names.
The main disadvantage of this approach is that it applies only to Java class files; it won't work for deploying HTML and JSP pages, much less entire Web applications.
An advantage of this approach, at least in some IDEs, is that it can deploy HTML and JSP pages and even entire Web applications, not just Java class files. A disadvantage is that it is an IDE-specific technique and thus is not portable across systems.
ant or a Similar Toolant is a tool
similar to the Unix make utility.
However, ant is written in the Java programming
language (and thus is portable)
and is touted to be both simpler to use and more powerful
than make. Many servlet
and JSP developers use ant for compiling and deploying.
The use of ant is especially
popular among Tomcat users and with those developing Web applications.
For general information on using ant, see
http://jakarta.apache.org/ant/manual/.
See
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/appdev/processes.html
for specific guidance on using ant with Tomcat.
The main advantage of this approach is flexibility:
ant is powerful enough to handle
everything from compiling the Java source code files, to copying class files, to producing
WAR files. The disadvantage of ant is the overhead of learning to use
it; there is more of a learning curve with ant
than with the other techniques in this section.
| Using Preconfigured Tomcat Versions |
|---|
If you prefer not to individually make each of the changes described in this tutorial, you can download a version of Tomcat that has all of these changes already made. In particular, these Tomcat versions:
PATH,
CLASSPATH, and JAVA_HOME variables.
Be sure you edit this file to refer to the proper JDK path,
and be sure to save your original autoexec.bat file, if you have one.
| More Information |
|---|
|
|