2.7 Set Up Your Development Environment

You configured and tested the server, so you're all set, right? Well, no, not quite. That's just the local deployment environment. You still have to set up your personal development environment. Otherwise, you won't be able to compile servlets and auxiliary Java classes that you write. Configuring your development environment involves the following steps.

  1. Creating a development directory. Choose a location in which to develop your servlets, JSP documents, and supporting classes.

  2. Setting your CLASSPATH . Tell the compiler about the servlet and JSP JAR file and the location of your development directory. Setting this variable incorrectly is the single most common cause of problems for beginners .

  3. Making shortcuts to start and stop the server. Make sure it is convenient to start and stop the server.

  4. Bookmarking or installing the servlet and JSP API documentation. You'll refer to this documentation frequently, so keep it handy.

The following subsections give details on each of these steps.

Creating a Development Directory

The first thing you should do is create a directory in which to place the servlets and JSP documents that you develop. This directory can be in your home directory (e.g., ~/ServletDevel on Unix) or in a convenient general location (e.g., C:\ServletDevel on Windows). It should not , however, be in the server's installation directory.

Eventually, you will organize this development directory into different Web applications (each with a common structuresee Section 2.11, "Web Applications: A Preview"). For initial testing of your environment, however, you can just put servlets either directly in the development directory (for packageless servlets) or in a subdirectory that matches the servlet package name . After compiling, you can simply copy the class files to the server's default Web application.

Many developers put all their code in the server's deployment directory (see Section 2.10). We strongly discourage this practice and instead recommend one of the approaches described in Section 2.9 (Establish a Simplified Deployment Method). Although developing in the deployment directory seems simpler at the beginning since it requires no copying of files, it significantly complicates matters in the long run. Mixing development and deployment locations makes it hard to separate an operational version from a version you are testing, makes it difficult to test on multiple servers, and makes organization much more complicated. Besides, your desktop is almost certainly not the final deployment server, so you'll eventually have to develop a good system for deploying anyhow.

Core Warning

graphics/bwopenglobe_icon.gif

Don't use the server's deployment directory as your development location. Instead, keep a separate development directory.


Setting Your CLASSPATH

Since servlets and JSP are not part of the Java 2 Platform, Standard Edition, you must identify the servlet classes to the compiler. The server already knows about the servlet classes, but the compiler (i.e., javac ) you use for development probably doesn't. So, if you don't set your CLASSPATH , attempts to compile servlets, tag libraries, or other classes that use the servlet API will fail with error messages about unknown classes. The exact location of the servlet JAR file varies from server to server. In most cases, you can hunt around in the install_dir /lib directory. Or, read your server's documentation to discover the location. Once you find the JAR file, add the location to your development CLASSPATH . Here are the locations for some common development servers:

  • Tomcat.

     
      install_dir  /common/lib/servlet.jar 
  • JRun.

     
      install_dir  /lib/jrun.jar 
  • Resin.

     
      install_dir  /lib/jsdk23.jar 

In addition to the servlet JAR file, you also need to put your development directory in the CLASSPATH . Although this is not necessary for simple packageless servlets, once you gain experience you will almost certainly use packages. Compiling a file that is in a package and that uses another class in the same package requires the CLASSPATH to include the directory that is at the top of the package hierarchy. In this case, that's the development directory we discussed in the first subsection. Forgetting this setting is perhaps the most common mistake made by beginning servlet programmers.

Core Approach

graphics/bwopenglobe_icon.gif

Remember to add your development directory to your CLASSPATH . Otherwise, you will get "Unresolved symbol" error messages when you attempt to compile servlets that are in packages and that make use of other classes in the same package.


Finally, you should include "." (the current directory) in the CLASSPATH . Otherwise, you will only be able to compile packageless classes that are in the top-level development directory.

Here are a few representative methods of setting the CLASSPATH . They assume that your development directory is C:\ServletDevel (Windows) or /usr/ServletDevel (Unix) and that you are using Tomcat 4. Replace install_dir with the actual base installation location of the server. Be sure to use the appropriate case for the filenames; they are case sensitive (even on a Windows platform!). If a Windows path contains spaces (e.g., C:\Documents and Settings\ Your Name \My Documents\... ), enclose it in double quotes. Note that these examples represent only one approach for setting the CLASSPATH . For example, you could create a script that invokes javac with a designated value for the -classpath option. In addition, many Java integrated development environments have a global or project-specific setting that accomplishes the same result. But those settings are totally IDE specific and aren't discussed here.

  • Windows 95/98/Me. Put the following in C:\autoexec.bat . (Note that this all goes on one line with no spacesit is broken here for readability.)

     
     set CLASSPATH=.;               C:\ServletDevel;  install_dir  \common\lib\servlet.jar 
  • Windows NT/2000/XP. Use the autoexec.bat file as above, or right-click on My Computer, select Properties, then System, then Advanced, then Environment Variables. Then, enter the CLASSPATH value from the previous bullet and click OK.

  • Unix (C shell). Put the following in your . cshrc . (Again, in the real file it goes on a single line without spaces.)

     
     setenv CLASSPATH .:                  /usr/ServletDevel:  install_dir  /common/lib/servlet.jar 

Making Shortcuts to Start and Stop the Server

During our development, we find ourselves frequently restarting the server. As a result, we find it convenient to place shortcuts to the server startup and shutdown icons inside the main development directory or on the desktop. You will likely find it convenient to do the same.

For example, for Tomcat on Windows, go to install_dir /bin , right-click on startup.bat , and select Copy. Then go to your development directory, right-click in the window, and select Paste Shortcut (not just Paste). Repeat the process for install_dir /bin/shutdown.bat . Some users like to put the shortcuts on the desktop or their Start menu. If you put the shortcuts there, you can even right-click on the shortcut, select Properties, then enter a keyboard shortcut by typing a key in the "Keyboard shortcut" text field. That way, you can start and stop the server just by pressing Control-Alt- SomeKey on your keyboard.

On Unix, you would use ln -s to make a symbolic link to startup.sh , tomcat.sh (needed even though you don't directly invoke this file), and shutdown.sh .

For JRun on Windows, go to the Start menu, select Programs, select Macromedia JRun 4, right-click on the JRun Launcher icon, and select Copy. Then go to your development directory, right-click in the window, and select Paste Shortcut (not just Paste). Repeat the process for the JRun Management Console if you so desire . There is no separate shutdown icon; the JRun Launcher lets you both start and stop the server.

For Resin on Windows, right-click on install_dir /bin/httpd.exe , and select Copy. Then go to your development directory, right-click in the window, and select Paste Shortcut (not just Paste). There is no separate shutdown icon; invoking httpd.exe results in a popup window with a Quit button that lets you stop the server.

Bookmarking or Installing the Servlet and JSP API Documentation

Just as no serious programmer should develop general-purpose Java applications without access to the Java 1.4 or 1.3 API documentation (in Javadoc format), no serious programmer should develop servlets or JSP pages without access to the API for classes in the javax.servlet packages. Here is a summary of where to find the API. (Remember that the source code archive at http://www.coreservlets.com/ has up-to-date links to all URLs cited in the book, in addition to the source code for all examples.)

  • http://java.sun.com/products/jsp/download.html

    This site lets you download the Javadoc files for the servlet 2.4 (JSP 2.0) or servlet 2.3 (JSP 1.2) APIs. You will probably find this API so useful that it will be worth having a local copy instead of browsing it online. However, some servers bundle this documentation, so check before downloading. (See the next bullet.)

  • On your local server

    Some servers come bundled with the servlet and JSP Javadocs. For example, with Tomcat, you can access the API by going to the default home page ( http://localhost/ ) and clicking on Tomcat Documentation and then Servlet/JSP Javadocs. Or, bookmark install_dir/webapps/tomcat-docs/catalina/docs/api/index.html; doing so lets you access the documentation even when Tomcat is not running. Neither JRun nor Resin bundles the API, however.

  • http://java.sun.com/products/servlet/2.3/javadoc/

    This site lets you browse the servlet 2.3 API online.

  • http://java.sun.com/j2ee/sdk_1.3/techdocs/api/

    This address lets you browse the complete API for version 1.3 of the Java 2 Platform, Enterprise Edition (J2EE), which includes the servlet 2.3 and JSP 1.2 packages.

  • http://java.sun.com/j2ee/1.4/docs/api/

    This address lets you browse the complete API for version 1.4 of the Java 2 Platform, Enterprise Edition (J2EE), which includes the servlet 2.4 and JSP 2.0 packages.



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

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