Welcome back to the JSP Corner. In this series, we're looking at developing Web applications using Java-Server Pages (JSP) and Jaguar CTS (aka EAServer).

In Part 1 of this series (PBDJ, Vol. 8, issue 9), we looked at the advantages JSP has over competitive dynamic page server technologies. We also examined page-based and class-based development. In this article, we'll look at setting up the development environment, so we can start building a Web application using JSP and servlet technologies.

First, though, a brief overview of the application that we'll be building together in the next few articles (before diving into the subject of this article).

The application that we'll develop is a basic shopping cart application that should look familiar to those who attended the "Build the Future" seminars held by Sybase. It's the eMusic Web site, which was originally written by Sybase in PowerDynamo. We'll rewrite the application using JSP and other J2EE technologies.

The Web application allows users to search for CDs online and add them to their shopping carts as future purchases. Figure 1 illustrates the flow users can take through the Web site and also shows the various pages we'll develop. Each section will be explained in more detail as they're built.

The Development Environment
Before we start on developing our application, we need to set up the development environment. In this series, we won't be using PowerJ (Sybase's Java IDE) - or any other Java IDE - to write our application because we need to get a better handle on the steps it takes to write a JSP application. I'll be using TextPad, which is a file editor with Java syntax highlighting. This editor is available from www.textpad.com. You can use this or any other editor you're comfortable with.

The development area will be set up to make the deployment of our Web application as easy as possible by mimicking the directory structure of the Web Archive file (WAR).

The WAR file is a collection of all the resources that make up the Web application packaged into a single file for deployment. The WAR file is defined in the Java Servlet 2.2 specification and provides a portable mechanism for deploying Web applications to different containers. Deploying JSP pages via the WAR file is covered in Appendix C of the JSP 1.1 specification.

The WAR file contains some or all of the following resources:

• JSP pages
• HTML pages
• Multimedia files (images, sounds, etc.)
• Servlets
• JavaBeans, utility Java classes, Tag library classes
• Applets

Once the WAR file is deployed into a container, the container extracts the files and stores them in its own directory structure. Tomcat uses the same format to store the resources as the WAR file, but Jaguar doesn't. The vendors have complete flexibility as to how to store the Web resources in their application servers, so our Web application can't assume this is the directory structure it will be stored in at runtime.

The WAR file has a root directory (or folder) that's the starting point for the hierarchy of our Web site. The root directory typically has the same name as the Web application context. Remember in Part 1 that the context is the part of the URL that specifies our application from any other Web application that may be running in the container. There's more to the context than this, but that should suffice for now.

The root directory of the WAR file is equivalent to the root directory of a Web site running on any Web server and is where all of the servable content goes. Servable content is the resource that can be returned directly to the client. This includes HTML pages, JSP pages, and multimedia files. The images folder shown in Figure 2 (under the root directory) isn't part of the defined WAR file format; the images and other multimedia files don't need to be placed in a separate directory. This, however, is something I recommend to help make the Web site more maintainable.

All resources accessible over the Web should be placed in the root directory using the same hierarchy that will be used to access the resources via a URL. For example, using the resources helloWorld.jsp and duke_wave.gif if we want to access the helloWorld.jsp file using the following URL:

localhost:8080\samples\helloWorld.jsp

And the duke_wave.gif file using the following URL:

localhost:8080\samples\images\duke_wave.gif

Then we should set up our root directory as shown in Figure 3.

Java classes, including servlets, don't go in the root directory. Even though servlets are technically accessible via a Web browser, they don't go in the same directory as the other servable Web resources. Under the root directory there's a special subdirectory named WEB-INF. This directory contains all the resources that aren't directly servable to a client. In fact, the Servlet 2.2 specification requires containers not to serve any files under this directory to the client.

There are two important subdirectories under WEB-INF: classes and lib. The lib directory is the area where Java Archive (JAR) files are placed. These JAR files can contain servlets, JavaBeans, and other utility Java classes that are used by the Web application. The classes' directory contains the .class files for servlets, JavaBeans, and utility Java classes that are used by the Web application. The container places the lib and classes directory in its CLASSPATH, so all of the Java classes are accessible by the Web application without any other changes to the server that the container is running on.

Under the classes' directory, each class must be placed in a directory hierarchy that mimics the Java package that it's part of. For example, the compiled Java class for the net.aegis.web.HelloWorld.java servlet (code sample shown below) is placed in a directory structure as shown in Figure 4.

package net.aegis.web;

// import statements...

public class HelloWorld extends HttpServlet {
...
}

The Deployment Descriptor
Under the WEB-INF directory is a file named web.xml. This file is the deployment descriptor and contains information and instructions that the container uses to configure itself to run the Web application. Some of the information in the deployment descriptor includes the names of the servlets and JSP pages, initialization parameters for servlets and JSP pages, URL mapping of servlets and JSP pages to different URLs, default Web pages, and environmental resources that are required by the application. We'll look at the deployment descriptor in more detail in a future article.

Building the WAR File
This is getting a bit ahead of ourselves, but now that we know how the WAR file is structured, we might as well take a look at how to create the WAR file. This is a simple process. At the command prompt, navigate to the root directory and type the following:

jar cvf samples.war .

The JAR command, which is part of the JDK, is used to create archive files. This command will add all the files and directories in the root directory and all of the directories and files under it to the new WAR file. Once this file is generated, it can be deployed to any servlet container that supports the Servlet 2.2 specification.

Build and Deploy
Based on the directory structure of the WAR file, we can set up a development environment that will make it easy for us to build and deploy our JSP Web applications. After reading this article you should be able to create a directory structure and know where to place various Web resources that you're creating. Next time we'll use this environment and start building our eMusic Web site using JSP and servlet technology.