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.
Verifying Your SDK InstallationOpen 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 ConfigurationFirst, 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.
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 . Figure 2-11. Result of Hello.jsp . 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 ServletsOK, 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 PackagesThe 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 . 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.
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 PackagesThe 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:
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).
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. Test 3: A Servlet That Uses Packages and UtilitiesThe 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
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.
Listing 2.5 coreservlets/HelloServlet3.javapackage 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 . |
EAN: 2147483647
Pages: 194
- Chapter I e-Search: A Conceptual Framework of Online Consumer Behavior
- Chapter VI Web Site Quality and Usability in E-Commerce
- Chapter XII Web Design and E-Commerce
- Chapter XV Customer Trust in Online Commerce
- Chapter XVI Turning Web Surfers into Loyal Customers: Cognitive Lock-In Through Interface Design and Web Site Usability