1.8. 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 (at least the default URL; in Section 5.3, “ Assigning Names and Custom URLs,” you’ll see how to customize that address). But how do you move the class files from the development directory to the deployment direc-tory? Copying each one by hand every time is tedious and error prone. Once you start using Web applications (see Chapter 4), 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.

Details on these four options are given in the following subsections.

Copy to a Shortcut or Symbolic Link

On Windows, go to the server’s default Web application, right-click on the classes directory, and select Copy. Then go to your development directory, right-click, and select Paste Shortcut (not just Paste). Now, whenever you compile a packageless servlet, just drag the class files onto the shortcut. When you develop in packages, use the right mouse to drag the entire directory (e.g., the moreservlets directory) onto the shortcut, release the mouse, and select Copy. On Unix/Linux, you can use symbolic links (created with 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 Chapter 4). Just make a shortcut to the main Web application directory (one level up from the top of the default Web application), and copy the entire Web application each time by using the right mouse to drag the directory that contains your Web application onto this shortcut and selecting Copy.

One disadvantage of this approach is that it requires repeated copying if you use multiple servers. For example, I keep at least two different servers on my development system and regularly test my code with both 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 may not matter much on your desktop server, but when you get to the “real” deployment server, you won’t want to include the source code files.

Use the -d Option of javac

By default, the Java compiler (javac) places class files in the same directory as the source code files that they came from. 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, with Tomcat I could compile the HelloServlet2 servlet (Listing 1.4, Section 1.7) 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.3/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 a subdirectory matching the package.

The main disadvantage is that this approach applies only to Java class files; it won’t work for deploying HTML and JSP pages, much less entire Web applications.

Let Your IDE Take Care of Deployment

Most servlet- and JSP-savvy development environments (e.g., IBM WebSphere Studio, Macromedia JRun Studio, Borland JBuilder) have options that let you tell the IDE where to deploy class files for your project. Then, when you tell the IDE to build the project, the class files are automatically deployed to the proper location (package-specific subdirectories and all).

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.

Use ant or a Similar Tool

Developed by the Apache foundation, ant 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 (see Chapter 4).

For general information on using ant, see http://jakarta.apache.org/ant/manual/. See http://jakarta.apache.org/tomcat/tomcat-4.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 to copying files to producing WAR files (Section 4.3). 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.