To add a context entry for the depfiles sample application, use the Add button, under the Application contexts section. A new entry with an empty text field under URL path and Application base directory columns will be added to the bottom of the list. Specify /depfiles for the URL path and /webapps/depfiles for the application base directory. Then, click on the Configure button of the new entry. This will open the ASF Tomcat Application Configuration display in another browser window. You don't need to change anything on this display for the sample application. Just click on the OK button and the default directories for the application will be created. For the sample application, a directory named depfiles will be be created under the /www/jkltest/webapps directory (the full path will be /www/jkltest/webapps/depfiles). You'll also notice a few other subdirectories created under the depfiles directory, such as WEB-INF, classes, and lib. (Those default directories won't be used here, but look for more information about these directories in a future article.) Before you leave the ASF Tomcat settings page, click the Apply button (located at the bottom of the page).

Once Tomcat is configured for your application the HTTP Server (powered by Apache) instance under which Tomcat is configured must be stopped and started (or restarted) to make the changes take affect.

Export/Publish a JSP Application to Tomcat

No matter what system (PC or iSeries) you use to develop or download your JSP application, you'll need to copy the application's source files and other resources--Java Beans, class packages, configuration files--to the appropriate directory of the Tomcat server. This process is sometimes referred to as exporting or publishing. (In the case of J2EE the process is called deployment of the Java application.)

For the sample application, copy the two source files (depfilesinput.html and depfilesoutput.jsp) available from the download to the /www/jkltest/webapps/depfiles directory.

How to Call a JSP from an Input Form

Now, let's look at the JSP application. The key to calling a JSP from an input form (in this case, depfilesinput.html) is the HTML form tag action attribute. I set the action attribute value to depfilesoutput.jsp to cause the depfilesoutput JSP to be called when the form is submitted. The form statement looks like this:

<form action="depfilesoutput.jsp" method="post">

I use post instead of get for one reason: I don't want the password field to appear in the URL parameter list that is automatically generated when the get method is used. The post method passes HTML form fields through the HTTP header, which is hidden from the average user. In a production application, you would actually want to take additional measures, such as using an SSL-enabled HTTP server.

There are other good reasons for using post instead of get, such as not allowing savvy browser users to bypass client-side validation processing, or if you wanted to pass more than 256 characters of data or pass more than just character data.

Retrieving the Input Form Fields

Once the user enters data on the input form and submits it, the JSP (depfilesoutput.jsp) is called. However, before the JSP can perform any processing, it needs to retrieve the information from the form. A JSP can obtain the value of HTML form fields through the getParameter method of the implicit request object. For example, to retrieve the value of an HTML input field called firstname and assign it to a variable called fName, your JSP could use the following scriptlet:

<% String fName = request.getParameter("firstname"); %>

In the depfilesoutput.jsp source file, you can see four getParameter methods being used near the beginning of the source code, right after the "// Get input fields" comment. The JSP uses these methods to retrieve the system name, user profile, password, and file name values from the HTML input form and to assign them to variables used by the JSP.

To better understand the implicit request object, it helps to know that, under the hood, your JSP is converted into a servlet, which by default uses two generic servlet objects: HTTPServletRequest and HTTPServletResponse. The HTTPServletRequest object actually represents the implicit request object of a JSP. An implicit response object is also available to JSPs, and that object is actually represented by the HTTPServletResponse object. Although the response object isn't used by the sample application, it's typically used for sending responses back to the browser client.

Using the Appropriate JDBC Driver

My previous article's JSP application used the IBM Toolbox for Java JDBC driver (type 4), because the application ran from a remote PC to access data on the iSeries system. A type 4 driver is appropriate for accessing a remote relational database because it converts the JDBC calls to the network protocol used by the relational database (e.g., DB2).

The depfiles sample application, however, does not need remote access to DB2, because it retrieves data from the same system on which the JSP is running. In this case, the native iSeries JDBC driver (type 2) is more appropriate and can be used to provide better performance. This driver is automatically made available to your Web application, but if you're curious about it's location, it can be found in the db2_classes.jar package, located in the iSeries Integrated File System:

/QIBM/ProdData/Java400/ext/db2_classes.jar

Running the Sample Application

Before you run the depfiles application, you need to ensure the HTTP server for which you configured Tomcat is running. To start the jkltest server instance, configured for the sample application from an OS/400 command line, use the following command:

STRTCPSVR SERVER(*HTTP) HTTPSVR(JKLTEST) 

Now open a browser window and use the following URL to activate the application:

http://<your_server>:<HTTPpbA_port>/depfiles/depfilesinput.html

If your HTTP Server (powered by Apache) uses the default port, which is 80, then :<HTTPpbA_port> is not required.

This application is relatively simple but is a great reference for creating other typical applications that accept user input, process it, and then create output. Of course, this application is Web-capable.

Coming Attractions

In my next article, you'll learn how to add powerful server-side validation (no JavaScript required) by enhancing the sample application presented here. The enhancement will enable the JSP to trap errors and gracefully report them back to the user. The enhancement will teach you how to forward processing from one JSP to another and more about parameter management between different JSPs.

A Quick Tomcat Tip

Here's a tip that could be helpful to know as you get further into JSP application development. If you've programmed in Java, you probably know your Java program doesn't always find the classes it needs. Often you find yourself updating your system's CLASSPATH environment variable to gain access to classes (whether they're stand-alone or part of a package).

With Tomcat, you have the option of either creating an entry for a JAR file in the Java classpath entries for your Tomcat server or simply copy the class or package in special Tomcat directories: WEB-INF/classes and WEB-INF/lib. (The WEB-INF/classes and WEB-INF/lib directories are automatically created when you add an application context entry to your Tomcat application and configure it.)

To add supporting stand-alone classes to your Tomcat application use this path:

/webapps/<your_application_directory>/WEB-INF/classes

To add JAR files to your Tomcat application use this path:

/webapps/<your_application_directory>/WEB-INF/lib

If, for example, your JSP application needed the IBM Toolbox for Java JAR file (jt400.jar), you could create a Java classpath entry for your Tomcat server that pointed to the physical location of the package, or you could copy jt400.jar to the WEB-INF/lib directory. In both cases, Tomcat will automatically make the jt400.jar package available to your JSP application, eliminating the need to worry about the CLASSPATH variable.