2.8 Test Your Setup

Before trying your own servlets or JSP pages, you should make sure that the SDK, the server, and your development environment are all configured properly. Verification involves the three steps summarized below; more details are given in the subsections following the list.

  1. Verifying your SDK installation. Be sure that both java and javac work properly.

  2. Checking your basic server configuration. Access the server home page, a simple user-defined HTML page, and a simple user -defined JSP page.

  3. Compiling and deploying some simple servlets. Try a basic packageless servlet, a servlet that uses packages, and a servlet that uses both packages and a utility (helper) class.

Verifying Your SDK Installation

Open a DOS window (Windows) or shell (Unix) and type java -version and javac -help . You should see a real result both times, not an error message about an unknown command. Alternatively, if you use an Integrated Development Environment (IDE), compile and run a simple program to confirm that the IDE knows where you installed Java. If either of these tests fails, review Section 2.1 (Download and Install the Java Software Development Kit (SDK)) and double-check the installation instructions that came with the SDK.

Checking Your Basic Server Configuration

First, start the server and access the standard home page ( http://localhost/ , or http://localhost: port/ if you did not change the port to 80). If this fails, review the instructions of Sections 2.32.6 and double-check your server's installation instructions.

After you have verified that the server is running, you should make sure that you can install and access simple HTML and JSP pages. This test, if successful, shows two important things. First, successfully accessing an HTML page shows that you understand which directories should hold HTML and JSP files. Second, successfully accessing a new JSP page shows that the Java compiler (not just the Java virtual machine) is configured properly.

Eventually, you will almost certainly want to create and use your own Web applications (see Section 2.11, "Web Applications: A Preview"), but for initial testing we recommend that you use the default Web application. Although Web applications follow a common directory structure, the exact location of the default Web application is server specific. Check your server's documentation for definitive instructions, but we summarize the locations for Tomcat, JRun, and Resin in the following list. Where we list SomeDirectory you can use any directory name you like. (But you are never allowed to use WEB-INF or META-INF as directory names . For the default Web application, you also must avoid a directory name that matches the URL prefix of any existing Web application such as samples or examples .) If you are running on your local machine, you can use localhost where we list host in the URLs.

  • Tomcat HTML/ JSP directory.

    install_dir /webapps/ROOT (or install_dir /webapps/ROOT/ SomeDirectory )

  • JRun HTML/ JSP directory.

    install_dir /servers/default/default-ear/default-war (or install_dir /servers/default/default-ear/default-war/ SomeDirectory )

  • Resin HTML/ JSP directory.

    install_dir /doc (or install_dir /doc/ SomeDirectory )

  • Corresponding URLs.

    http:// host /Hello.html (or http:// host/SomeDirectory /Hello.html )

    http:// host /Hello.jsp (or http:// host/SomeDirectory /Hello.jsp )

For your first tests, we suggest you simply drop Hello.html (Listing 2.1, Figure 2-10) and Hello.jsp (Listing 2.2, Figure 2-11) into the appropriate locations. For now, don't worry about what the JSP document does; we'll cover that later. The code for these files, as well as all the code from the book, is available online at http://www.coreservlets.com/. That Web site also contains links to all URLs cited in the book, updates, additions, information on training courses, and other servlet and JSP resources. It also contains a frequently updated page on Tomcat configuration (since Tomcat changes more often than the other servers).

Figure 2-10. Result of Hello.html .

graphics/02fig10.jpg

Figure 2-11. Result of Hello.jsp .

graphics/02fig11.jpg

If neither the HTML file nor the JSP file works (e.g., you get File Not Found404errors), you probably are either using the wrong directory for the files or misspelling the URL (e.g., using a lowercase h in Hello.jsp ). If the HTML file works but the JSP file fails, you probably have incorrectly specified the base SDK directory (e.g., with the JAVA_HOME variable) and should review Section 2.7 (Set Up Your Development Environment).

Listing 2.1 Hello.html
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD><TITLE>HTML Test</TITLE></HEAD> <BODY BGCOLOR="#FDF5E6"> <H1>HTML Test</H1> Hello. </BODY></HTML> 
Listing 2.2 Hello.jsp
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD><TITLE>JSP Test</TITLE></HEAD> <BODY BGCOLOR="#FDF5E6"> <H1>JSP Test</H1> Time: <%= new java.util.Date() %> </BODY> </HTML> 

Compiling and Deploying Some Simple Servlets

OK, so your development environment is all set. At least you think it is. It would be nice to confirm that hypothesis. Following are three test servlets that help verify it.

Test 1: A Servlet That Does Not Use Packages

The first servlet to try is a basic one: no packages, no utility (helper) classes, just simple HTML output. Rather than writing your own test servlet, you can just download HelloServlet.java (Listing 2.3) from the book's source code archive at http://www.coreservlets.com/. Again, don't worry about how this servlet worksthat is covered in detail in the next chapterthe point here is just to test your setup. If you get compilation errors, go back and check your CLASSPATH settings (Section 2.7)you most likely erred in listing the location of the JAR file that contains the servlet classes (e.g., servlet.jar ).

Once you compile HelloServlet.java , put HelloServlet.class in the appropriate location (usually the WEB-INF/classes directory of your server's default Web application). Check your server's documentation for this location, or see the following list for a summary of the locations used by Tomcat, JRun, and Resin. Then, access the servlet with the URL http:// host /servlet/HelloServlet (or http:// host:port /servlet/HelloServlet if you chose not to change the port number as described in Section 2.3). Use localhost for host if you are running the server on your desktop system. You should get something similar to Figure 2-12. If this URL fails but the test of the server itself succeeded, you probably put the class file in the wrong directory.

Figure 2-12. Result of http://localhost/servlet/HelloServlet .

graphics/02fig12.jpg

Notice that you use servlet (not servlets !) in the URL even though there is no real directory named servlet . URLs of the form .../servlet/ ServletName are just an instruction to a special servlet (called the invoker servlet ) to run the servlet with the specified name. The servlet code itself is in any of the locations the server normally uses (usually, .../WEB-INF/classes for individual class files or .../WEB-INF/lib for JAR files that contain servlets). Using default URLs like this is convenient during your initial development, but once you are ready to deploy, you will almost certainly disable this capability and register a separate URL for each servlet. See Section 2.11 (Web Applications: A Preview) for details. In fact, servers are not strictly required to support these default URLs, and some of the high-end application servers, most notably BEA WebLogic, do not.

  • Tomcat directory for Java .class files.

    install_dir /webapps/ROOT/WEB-INF/classes (Note: in many Tomcat versions, you'll have to manually create the classes directory.)

  • JRun directory for Java .class files.

     
      install_dir  /servers/default/default-ear/default-war/WEB-INF/classes 
  • Resin directory for Java .class files.

     
      install_dir  /doc/WEB-INF/classes 
  • Corresponding URL.

    http:// host /servlet/HelloServlet

Listing 2.3 HelloServlet.java
 import java.io.*; import javax.servlet.*; import javax.servlet.http.*; /** Simple servlet used to test server. */ public class HelloServlet extends HttpServlet {   public void doGet(HttpServletRequest request,                     HttpServletResponse response)       throws ServletException, IOException {     response.setContentType("text/html");     PrintWriter out = response.getWriter();     String docType =       "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 " +       "Transitional//EN\">\n";     out.println(docType +                 "<HTML>\n" +                 "<HEAD><TITLE>Hello</TITLE></HEAD>\n" +                 "<BODY BGCOLOR=\"#FDF5E6\">\n" +                 "<H1>Hello</H1>\n" +                 "</BODY></HTML>");   } } 
Test 2: A Servlet That Uses Packages

The second servlet to try is one that uses packages but no utility classes. Packages are the standard mechanism for preventing class name conflicts in the Java programming language. There are three standard rules to remember:

  1. Insert package declarations in the code. If a class is in a package, it must have " package packageName ; " as the first noncomment line in the source code.

  2. Use a directory that matches the package name. If a class is in a package, it must be in a directory that matches its package name. This is true for class files in both development and deployment locations.

  3. From Java code, use dots after packages. When you refer to classes that are in packages either from within Java code or in a URL, you use a dot, not a slash, between the package name and the class name.

Again, rather than writing your own test, you can grab HelloServlet2.java (Listing 2.4) from the book's source code archive at http://www.coreservlets.com/. Since this servlet is in the coreservlets package, it should go in the coreservlets directory, both during development and when deployed to the server. If you get compilation errors, go back and check your CLASSPATH settings (Section 2.7)you most likely forgot to include "." (the current directory). Once you compile HelloServlet2.java , put HelloServlet2.class in the coreservlets subdirectory of whatever directory the server uses for servlets that are not in custom Web applications (usually the WEB-INF/ classes directory of the default Web application). Check your server's documentation for this location, or see the following list for a summary of the locations for Tomcat, JRun, and Resin. For now, you can simply copy the class file from the development directory to the deployment directory, but Section 2.9 (Establish a Simplified Deployment Method) provides some options for simplifying the process.

Once you have placed the servlet in the proper directory, access it with the URL http://localhost/servlet/coreservlets.HelloServlet2 . Note that there is a dot, not a slash, between the package name and the servlet name in the URL. You should get something similar to Figure 2-13. If this test fails, you probably either typed the URL wrong (e.g., failed to maintain the proper case) or put HelloServlet2.class in the wrong location (e.g., directly in the server's WEB-INF/classes directory instead of in the coreservlets subdirectory).

  • Tomcat directory for packaged Java classes.

     
      install_dir  /webapps/ROOT/WEB-INF/classes/coreservlets 
  • JRun directory for packaged Java classes.

     
      install_dir  /servers/default/default-ear/default-war/WEB-INF/classes/coreservlets 
  • Resin directory for packaged Java classes.

     
      install_dir  /doc/WEB-INF/classes/coreservlets 
  • Corresponding URL.

    http:// host /servlet/coreservlets.HelloServlet2

Listing 2.4 coreservlets/HelloServlet2.java
  package coreservlets;  import java.io.*; import javax.servlet.*; import javax.servlet.http.*; /** Simple servlet for testing the use of packages. */ public class HelloServlet2 extends HttpServlet {   public void doGet(HttpServletRequest request,                     HttpServletResponse response)       throws ServletException, IOException {     response.setContentType("text/html");     PrintWriter out = response.getWriter();     String docType =       "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 " +       "Transitional//EN\">\n";     out.println(docType +                 "<HTML>\n" +                 "<HEAD><TITLE>Hello (2)</TITLE></HEAD>\n" +                 "<BODY BGCOLOR=\"#FDF5E6\">\n" +                 "<H1>Hello (2)</H1>\n" +                 "</BODY></HTML>");   } } 
Figure 2-13. Result of http://localhost/servlet/coreservlets.HelloServlet2 . Note that it is a dot, not a slash, between the package name and the class name.

graphics/02fig13.jpg

Test 3: A Servlet That Uses Packages and Utilities

The final servlet you should test to verify the configuration of your server and development environment is one that uses both packages and utility classes. Listing 2.5 presents HelloServlet3.java , a servlet that uses the ServletUtilities class (Listing 2.6) to simplify the generation of the DOCTYPE (specifies the HTML versionuseful 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. Again, the source code can be found at http://www.coreservlets.com/.

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, go back and check your CLASSPATH settings (Section 2.7)you most likely forgot to include the top-level development directory. We've said it before, but we'll say it again: your CLASSPATH must include the top-level directory of your package hierarchy before you can compile a packaged class that makes use of another class that is in the same package or in any other user-defined (nonsystem) 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 problems that beginning developers encounter. Furthermore, as we will see later, you must put all utility classes you write into packages if you want to use them from JSP pages, so virtually all the auxiliary classes (and most of the servlets) you write will be in packages. You might as well get used to the process of using packages now.

Core Warning

graphics/bwopenglobe_icon.gif

Your CLASSPATH must include your top-level development directory. Otherwise, you will get " unresolved symbol" errors when you attempt to compile servlets that are in packages and that also use user-defined classes that are in packages.


Once you compile HelloServlet3.java (which will automatically cause ServletUtilities.java to be compiled), put HelloServlet3.class and ServletUtilities.class in the coreservlets subdirectory of whatever directory the server uses for servlets that are not in custom Web applications (usually the WEB-INF/classes directory of the default Web application). Check your server's documentation for this location, or see the following list for a summary of the locations used by Tomcat, JRun, and Resin. Then, access the servlet with the URL http://localhost/servlet/coreservlets.HelloServlet3 . You should get something similar to Figure 2-14.

  • Tomcat directory for packaged Java classes.

     
      install_dir  /webapps/ROOT/WEB-INF/classes/coreservlets 
  • JRun directory for packaged Java classes.

     
      install_dir  /servers/default/default-ear/default-war/WEB-INF/classes/coreservlets 
  • Resin directory for packaged Java classes.

     
      install_dir  /doc/WEB-INF/classes/coreservlets 
  • Corresponding URL.

    http:// host /servlet/coreservlets.HelloServlet3

Listing 2.5 coreservlets/HelloServlet3.java
  package coreservlets;  import java.io.*; import javax.servlet.*; import javax.servlet.http.*; /** Simple servlet for testing the use of packages  *  and utilities from the same package.  */ public class HelloServlet3 extends HttpServlet {   public void doGet(HttpServletRequest request,                     HttpServletResponse response)       throws ServletException, IOException {     response.setContentType("text/html");     PrintWriter out = response.getWriter();     String title = "Hello (3)";     out.println(  ServletUtilities.headWithTitle(title)  +                 "<BODY BGCOLOR=\"#FDF5E6\">\n" +                 "<H1>" + title + "</H1>\n" +                 "</BODY></HTML>");   } } 
Listing 2.6 coreservlets/ServletUtilities.java (Excerpt)
  package coreservlets;  import javax.servlet.*; import javax.servlet.http.*; /** Some simple time savers. Note that most are static methods. */ public class ServletUtilities {   public static final String DOCTYPE =     "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 " +     "Transitional//EN\">";   public static String headWithTitle(String title) {     return(DOCTYPE + "\n" +            "<HTML>\n" +            "<HEAD><TITLE>" + title + "</TITLE></HEAD>\n");   }   ... } 
Figure 2-14. Result of http://localhost/servlet/coreservlets.HelloServlet3 .

graphics/02fig14.jpg



Core Servlets and JavaServer Pages (Vol. 1.Core Technologies)
Core Servlets and Javaserver Pages: Core Technologies, Vol. 1 (2nd Edition)
ISBN: 0130092290
EAN: 2147483647
Year: 2002
Pages: 194

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net