| Your second step is to download a server (often called a "servlet container" or "servlet engine") that implements the Servlet 2.3 Specification (JSP 1.2) or the Servlet 2.4 Specification (JSP 2.0) for use on your desktop. In fact, we typically keep three servers (Apache Tomcat, Macromedia JRun, and Caucho Resin) installed on our desktops and test applications on all the servers, to keep us aware of cross-platform deployment issues and to prevent us from accidentally using nonportable features. We'll give details on each of these servers throughout the book. Regardless of the server that you use for final deployment, you will want at least one server on your desktop for development. Even if the deployment server is in the office next to you connected by a lightning-fast network connection, you still don't want to use it for your development. Even a test server on your intranet that is inaccessible to customers is much less convenient for development purposes than a server right on your desktop. Running a development server on your desktop simplifies development in a number of ways, as compared to deploying to a remote server each and every time you want to test something. Here is why: -
It is faster to test. With a server on your desktop, there is no need to use FTP or another upload program. The harder it is for you to test changes, the less frequently you will test. Infrequent testing will let errors persist that will slow you down in the long run. -
It is easier to debug. When running on your desktop, many servers display the standard output in a normal window. This is in contrast to deployment servers on which the standard output is almost always either hidden or only available in a log file after execution is completed. So, with a desktop server, plain old System.out.println statements become useful tracing and debugging utilities. -
It is simple to restart. During development, you will find that you frequently need to restart the server or reload your Web application. For example, the server typically reads the web.xm l file (see Section 2.11, "Web Applications: A Preview") only when the server starts or a server-specific command is given to reload a Web application. So, you normally have to restart the server or reload the Web application each time you modify web.xml . Even when servers have an interactive method of reloading web.xml , tasks such as clearing session data, resetting the ServletContext , or replacing modified class files used indirectly by servlets or JSP pages (e.g., beans or utility classes) may still necessitate that the server be restarted. Some older servers also need to be restarted because they implement servlet reloading unreliably. (Normally, servers instantiate the class that corresponds to a servlet only once and keep the instance in memory between requests . With servlet reloading , a server automatically replaces servlets that are in memory but whose class files have changed on the disk.) Besides, some deployment servers recommend completely disabling servlet reloading to increase performance. So, it is much more productive to develop in an environment in which you can restart the server or reload the Web application with a click of the mousewithout asking for permission from other developers who might be using the server. -
It is more reliable to benchmark. Although it is difficult to collect accurate timing results for short-running programs even in the best of circumstances, running benchmarks on multiuser systems that have heavy and varying system loads is notoriously unreliable. -
It is under your control. As a developer, you may not be the administrator of the system on which the test or deployment server runs. You might have to ask some system administrator every time you want the server restarted. Or, the remote system may be down for a system upgrade at the most critical juncture of your development cycle. Not fun. -
It is easy to install. Downloading and configuring a server takes no more than an hour . By using a server on your desktop instead of a remote one, you'll probably save yourself that much time the very first day you start developing. If you can run the same server on your desktop that you use for deployment, all the better. So, if you are deploying on BEA WebLogic, IBM WebSphere, Oracle9i AS, etc., and your license permits you to also run the server on your desktop, by all means do so. But one of the beauties of servlets and JSP is that you don't have to; you can develop with one server and deploy with another. Following are some of the most popular free options for desktop development servers. In all cases, the free version runs as a standalone Web server. In most cases, you have to pay for the deployment version that can be integrated with a regular Web server like Microsoft IIS, iPlanet/Sun ONE Server, Zeus, or the Apache Web Server. However, the performance difference between using one of the servers as a servlet and JSP engine within a regular Web server and using it as a complete standalone Web server is not significant enough to matter during development. See http://java.sun.com/products/servlet/industry.html for a more complete list of servers and server plugins that support servlets and JSP. -
Apache Tomcat. Tomcat 5 is the official reference implementation of the servlet 2.4 and JSP 2.0 specifications. Tomcat 4 is the official reference implementation for servlets 2.3 (JSP 1.2). Both versions can be used as standalone servers during development or can be plugged into a standard Web server for use during deployment. Like all Apache products, Tomcat is entirely free and has complete source code available. Of all the servers, it also tends to be the one that is most compliant with the latest servlet and JSP specifications. However, the commercial servers tend to be better documented, easier to configure, and faster. To download Tomcat, start at http://jakarta.apache.org/tomcat/, go to the binaries download section, and choose the latest release build of Tomcat. -
Macromedia JRun. JRun is a servlet and JSP engine that can be used in standalone mode for development or plugged into most common commercial Web servers for deployment. It is free for development purposes, but you must purchase a license before deploying with it. It is a popular choice among developers looking for easier administration than Tomcat. For details, see http://www.macromedia.com/software/jrun/. -
Caucho's Resin. Resin is a fast servlet and JSP engine with extensive XML support. Along with Tomcat and JRun, it is one of the three most popular servers used by commercial Web hosting companies that provide servlet and JSP support. It is free for development and noncommercial deployment purposes. For details, see http://caucho.com/products/resin/. -
New Atlanta's ServletExec. ServletExec is another popular servlet and JSP engine that can be used in standalone mode for development or, for deployment, plugged into the Microsoft IIS, Apache, and Sun ONE servers. You can download and use it for free, but some of the high-performance capabilities and administration utilities are disabled until you purchase a license. The ServletExec Debugger is the configuration you would use as a standalone desktop development server. For details, see http://www.newatlanta.com/products/servletexec/. -
Jetty. Jetty is an open -source server that supports servlets and JSP technology and is free for both development and deployment. It is often used as a complete standalone server (rather than integrated inside a non-Java Web server), even for deployment. For details, see http://jetty.mortbay.org/jetty/.  |
