Download Setting Up a Servlet and JSP Environment and more Lecture notes Technology in PDF only on Docsity!
Chapter 1
Setting Up a Servlet and JSP
Environment
B efore you start developing with Servlets and JavaServer Pages, you need to
understand two very important things: Why is using the technology desirable, and what is needed in order to use the technology? This chapter answers these two questions, and in the process provides an introduction to the entire book. We start with an introduction to traditional Web development. The discussion describes why Servlets and JSP were initially created and why the technologies are currently popular. The end of the discussion segues to the software needed in order to run the book’s examples. It is preferred that you follow the instructions in this chapter to ensure your coding environment most closely matches the one all of the code examples of this book have been tested against. If you are using an already established Servlet/JSP environment, make sure it has support for JavaServer Pages 2.0, Servlets 2.4, and the Java 2 Standard Edition 1.4. Examples in this book require these technologies and some features covered are not backwards-compatible.
A Quick History of Web Development
The Servlet and JSP environment extends past the need for basic Java support. Any computer running JSP or Servlets needs to also have a container. A container is a piece of software responsible for loading, executing, and unloading the Servlets and JSP. The reasons for this are largely related to the history of server-side Web development. A quick overview of one of the earliest and most prominent server- side dynamic content solutions, CGI, and the differences between it and Servlets
1
2 SETTING UP A SERVLET AND JSP ENVIRONMENT
is very helpful in understanding why a JSP/Servlet container is required. The exact life cycle events that are managed by a container are discussed in Chapter 2.
CGI The Common Gateway Interface, or CGI, is commonly referred to as one of the first practical technologies for creating dynamic server-side content. With CGI a server passes a client’s request to an external program. This program executes, creates some content, and sends a response to the client. When first developed, this functionality was a vast improvement over static content and greatly expanded the functionality available to a Web developer. Needless to say CGI quickly grew in popularity and became a standard method for creating dynamic Web pages. However, CGI is not perfect. CGI was originally designed to be a standard method for a Web server to communicate with external applications. An interesting point to note is that the functionality available for generating dynamic Web pages was really a side effect of this design goal. This largely explains why CGI has maybe the worst life cycle possible. As designed, each request to a CGI resource creates a new process on the server and passes information to the process via standard input and environment variables. Figure 1-1 provides a diagram of this single-phase CGI life cycle. While it does work, the CGI life cycle is very taxing on server resources and greatly limits the number of concurrent CGI users a server can support. In case you are unfamiliar with operating systems and processes, a good analogy to use would be starting up and shutting down a Web server each time a user makes a request. As you probably know, this is almost never the case for a real Web server. It takes a noticeable amount of time to start and stop the entire process. A better solution is to start the server process once, handle all requests, and then
CGI Process
CGI Process
CGI Process
Request
Request
Request
CGI Web Server
Figure 1-1 CGI Life Cycle
Java Servlets In the Java world, Servlets were designed to solve the problems of CGI and create robust server-side environments for Web developers. Similar to CGI, Servlets allow a request to be processed by a program and let the same program produce a dynamic response. Servlets additionally defined an efficient life cycle that included the possibility of using a single process for managing all requests. This eliminated the multi-process overhead of CGI and allowed for the main process to share resources between multiple Servlets and multiple requests. Figure 1- gives a diagram of a Web server with Servlet support. The Servlet diagram is similar to that of second-generation CGI, but notice all the Servlets run from one main process, or a parent program. This is one of the keys to Servlet efficiency, and, as we will see later, the same efficiency is found with JSP. With an efficient design and Java’s cross-platform support, Servlets solved the common complaints of CGI and quickly became a popular solution to dynamic server-side functionality. Servlets are still popular and are now also used as the foundation for other technologies such as JSP. Currently, Servlets and JSP com- bined make up the official “Web Tier” for the Java 2 Enterprise Edition, J2EE^1.
Containers
Servlet performance can be attributed directly to a Servlet container. A Servlet container, also called “container” or “JSP container”, is the piece of software
4 SETTING UP A SERVLET AND JSP ENVIRONMENT
Servlet
Servlet
Servlet
Request
Request
Request
Web Server Process
Figure 1-3 Servlet Web Server Diagram
- This book’s title, The J2EE Technology Web Tier , comes directly from the marketing jargon Sun uses. Logically, Web Tier means the code that interacts with the World Wide Web.
that manages the Servlet life cycle. Container software is responsible for inter- acting with a Web server to process a request and passing it to a Servlet for a response. The official definition of a container is described fully by both the JSP and Servlet specifications. Unlike most proprietary technologies, the JSP and Servlet specifications only define a standard for the functionality a con- tainer must implement. There is not one but many different implementations of Servlet and JSP containers from different vendors with different prices, per- formance, and features. This leaves a Servlet and JSP developer with many options for development software. With containers in mind, the previous diagram of Servlets is better drawn using a container to represent the single process that creates, manages, and destroys threads running Servlets on a Web server. Note that this may or may not be a separate physical process. Figure 1-4 shows a Web server using a Servlet con- tainer. Only Servlets are depicted in Figure 1-3, but in the next two chapters the Servlet and JSP life cycles are covered in detail, and it will be clear that a con- tainer manages JSP in exactly the same way as Servlets. For now it is safe to assume that Servlets and JSP are the same technology. What Figure 1-4 does not show is that in some cases a container also acts as the Web server rather than a module to an existing server. In these cases the Web server and container in Figure 1-3 are essentially the same thing. Given you now know a little more about containers, it should be clear that a container must be installed to run Servlets and JSP. Examples in this book require a Servlet 2.4 and JSP 2.0-compatible container. If you do not have one, do not worry. A walk-through is provided later in this chapter, explaining how to obtain
CONTAINERS 5
CGI Process
CGI Process
CGI Process
Request
Request
Request
Web Server Container
Figure 1-4 Container Process
GETTING JAVA SUPPORT 7
Java only needs to be installed once on your computer and only for the spe- cific operating system you are using. It is not required that you read all of the sections covering installation on all of the featured platforms. They exist only to give readers a guide to their specific operating system. Complete coverage of the Java 2 Standard Edition 1.4 is outside the scope of this book; however, later use of the J2SDK by this book will not require comprehensive knowledge of the tools provided by Sun. If you are looking for a detailed guide for this infor- mation, refer to Thinking In Java, 3 rd^ Edition^2 , by Bruce Eckel.
Installing J2SE 1.4 on Microsoft Windows Microsoft Windows comes in many varieties, with early versions having a big dis- tinction between a desktop computer and a computer designed to be a server. Practically speaking, a desktop computer running Windows 95 or Windows 98 is a not a good choice for installing a production environment for Servlets and JSP, but a Windows 95 or Windows 98 computer will suffice in order to try this book’s examples. The Java distribution for Microsoft Windows will run on all versions of the operating system excluding Windows 3.x. In this book, the focus is on installing Java on a Windows NT, 2000, or XP computer. However, we realize that many readers have a desktop PC running Windows 95 or Windows 98 at home. An attempt will be made to help you if this is the case. After downloading the J2SE 1.4, it must be installed on your system. The download should be an executable file that can be run by double-clicking it. Double-click on this file and follow the installation wizard through all the steps. It does not matter where you install the J2SE 1.4, but it is worth noting the location, as it is needed in a later part of this chapter. Installation of the Java 2 Standard Development Kit 1.4 is now complete. Skip ahead to the section entitled, “Tomcat”.
Installing J2SE 1.4 on Linux Distributions Linux comes in far more varieties than Windows and operates on many more hardware architectures. A walk-through installation guide for all Linux distribu- tions is not attempted, but this guide should work on the vast majority of distri- butions. Specifically this section gives a walk-through of installing the J2SE 1. on Red Hat Linux 7.3. It will greatly resemble installation on any Linux distri- bution for x86 processors, as an RPM is not used. If you downloaded the RPM or
- A free copy of the book can be found online, http://www.mindview.net/Books/TIJ/.
8 SETTING UP A SERVLET AND JSP ENVIRONMENT
equivalent for your distribution, feel free to install it, make note of the instal- lation directory, and skip to the next section of this chapter. At the introduction to this section, you should have downloaded the J2SE 1. Linux binary installation file. The file should be named something similar to j2sdk-1_4_0_01-linux-i586.bin with appropriate version numbers for the latest release. Any post-1.4 release should be adequate; this guide uses version 1.4.0_01. From the command prompt make sure the file has executable permis- sions and execute the program. These are what the commands would be to make the file executable and then execute it; assume the download is in the /root/download directory and you have proper permissions.
chmod +x /root/download/j2sdk-1_4_0_01-linux-i586.bin /root/download/j2sdk-1_4_0_01-linux-i586.bin
When the file executes, Sun’s licensing terms are displayed and you have the option of agreeing to continue the installation. Figure 1-5 shows an example display of the licensing terms. If you agree to the terms, files will automatically be unpacked to a j2sdk1.4.0 directory created by the installation program. You can move this directory to any location you prefer, but remember the location where the J2SDK 1.4 is because it will be needed later when the environment variables are set. Installation of the standard Java development kit is now complete.
Figure 1-5 Sun’s J2SDK 1.4 Licensing Terms
10 SETTING UP A SERVLET AND JSP ENVIRONMENT
Figure 1-6 should appear notifying you that the Tomcat Installer located a J2SDK installation. Click OK and continue on to the screen displaying the Apache Software Foundation license. Read through the terms and make sure you agree with Tomcat’s licensing. If you accept the terms, the installation continues and you can choose what components you wish to install. The default ones should be fine, as shown in Figure 1-7. Proceed with the installation wizard to the next screen, and you can choose a directory to install Tomcat. Figure 1-8 shows the corresponding installation wizard screen. Choose any directory you prefer. After choosing an installation directory, the wizard will ask for some initial Tomcat configuration information, including a port number and administrative access information. The default options are fine, but later on in the chapter we will be changing the port Tomcat uses to be port 80 instead of 8080. You may change the port to 80 via the installation wizard now or later on in the chapter. Figure 1-9 displays the corresponding installation wizard screen. The final piece of configuration information Tomcat requires is the location of your Java Virtual Machine, which should be wherever you installed it earlier in the chapter. By default Tomcat attempts to locate the most recent JVM for you, as shown in Figure 1-10.
Figure 1-6 Windows Installation Wizard
GETTING JAVA SUPPORT 11
Figure 1-7 Installation Wizard Choosing Tomcat’s Components
Figure 1-8 Installation Wizard for Installing Tomcat
GETTING JAVA SUPPORT 13
The default JVM found by the installation wizard should be fine, but you can change the location to be any JVM you desire (note a Java 1.4-compatible JVM is required to execute this book’s examples). Finally, the installation wizard will automatically install all the Tomcat files. Figure 1-11 shows the corresponding installation wizard screen. To complete the installation and run Tomcat, start the server by double- clicking on the Tomcat icon or by executing the startup script startup.bat found in the TOMCAT_HOME/bin directory. Check the service is running by browsing to your local computer on port 8080 (or 80 if you changed Tomcat’s port via the installation wizard), http://127.0.0.1:8080. A Tomcat welcome page should be displayed 4 as shown in Figure 1-12. Installation of Tomcat is complete, and you are now ready to run book examples. Tomcat comes bundled with documentation and examples of both Servlets and JSP. Feel free to examine the bundled examples, but this book will not cover them further. Before continuing, there are two important scripts to be aware of.
Figure 1-11 Installation Wizard for Installing Tomcat Files
- Port 8080 should not be previously in use, but if it is, you will not be able to see the Tomcat welcome page. If you are sure you have correctly installed Tomcat and think a port bind is causing problems, consult the later section in this chapter which deals with changing the port Tomcat runs on.
14 SETTING UP A SERVLET AND JSP ENVIRONMENT
- startup.bat: The startup.bat script in the TOMCAT_HOME/bin directory is used to start the Tomcat container and Web server. Servlet and JSP code examples rely on Tomcat, and you must have Tomcat turned on before testing them. - shutdown.bat: The shutdown.bat script in the TOMCAT_HOME/bin directory is used to terminate the Tomcat container and Web server.
It is important to be aware of these two scripts because from time to time an example will require that Tomcat be restarted. When this is asked, it is assumed Tomcat is currently running and implies that the shutdown.bat script and then startup.bat be executed to reload the server. Alternatively you can also use an automated utility like Ant, which is discussed later in this chapter, to manage reloading, compiling, and other repetitive aspects of developing Servlets and JSP.
Windows 9X/ME “out of environment space” Just because you are using Windows 9x, or Millennium, does not mean you will have a problem, but be aware that a common problem does exist. If when exe- cuting startup.bat or shutdown.bat, an “out of environment space” error
Figure 1-12 Tomcat Welcome Page after Completing the Installation
two environment variables. The commands would be similar to the following if the J2SDK is installed in the /usr/java/jdk1.4 directory and Tomcat 5 is installed in the /usr/jakarta-tomcat-5.0 directory; replace each variable accordingly to match your specific case:
JAVA_HOME=/usr/java/jdk1. TOMCAT_HOME=/usr/jakarta-tomcat-5. export JAVA_HOME TOMCAT_HOME
Tomcat is now ready to run. Start the server by executing the startup script startup.sh found in the /usr/jakarta-tomcat-5.0/bin directory. Check the service is running by browsing to your local computer on port 8080, http://127.0.0.1:8080. A Tomcat welcome page should be displayed 6 as shown in Figure 1-13. Installation of Tomcat is complete, and you are now ready to run book examples. Tomcat comes bundled with documentation and examples of both Servlets and JSP. Feel free to examine the bundled examples, but this book will
16 SETTING UP A SERVLET AND JSP ENVIRONMENT
Figure 1-13 Tomcat Welcome Page Appears after Starting Tomcat
- Port 8080 should not be previously in use, but if it is, you will not be able to see the Tomcat welcome page. If you are sure you have correctly installed Tomcat and think a port bind is causing problems, consult the later section in this chapter, which deals with changing the port Tomcat runs on.
not cover them further. Before continuing on, there are two important scripts to be aware of.
- startup.sh: The startup.sh script in the TOMCAT_HOME/bin directory is used to start the Tomcat container and Web server. Servlet and JSP code examples rely on Tomcat, and you must have Tomcat turned on before testing them. - shutdown.sh: The shutdown.sh script in the TOMCAT_HOME/bin directory is used to terminate the Tomcat container and Web server.
It is important to be aware of these two scripts because from time to time an example will require that Tomcat be restarted. When this is asked, it is assumed Tomcat is currently running and implies that the shutdown.sh script and then startup.sh be executed to reload the server. Also be aware that the environment variables previously set will not persist between different ter- minal sessions and need to either be included in a startup script or set for each session. Alternatively, you can also automate the redundant process of compiling book examples and reloading Tomcat by using a build utility. Use of the Jakarta Ant build utility is strongly encouraged with this book and is covered later in this chapter.
Configuring Tomcat Tomcat is a robust JSP and Servlet container. It not only provides complete support for the JSP and Servlet specifications, but it can also act as a standalone Web server. By default, this is exactly what Tomcat does, and the default configu- ration is all we need for this book’s examples. Full instructions on configuring Tomcat are outside the scope of this book. There are many different Servlet and JSP containers available, and it is not very practical to devote a large part of this book to Tomcat-specific information. There is only one important aspect of con- figuring Tomcat that needs to be discussed. If you would like to learn more about using Tomcat to its full potential, some good resources are listed at the end of this section.
Switching Tomcat to Port 80, the Default HTTP Port For all practical purposes it does not matter what port you run Tomcat on. Ports 8080, 80, 1234, and 9999 all work the same. However, any port besides 80, which is being used for HTTP, comes with some slight annoyances that it would be nice to avoid. Specifically, the default port for HTTP is port 80. Recall
GETTING JAVA SUPPORT 17
Tomcat User’s Guide The Tomcat’s User’s Guide is the official documentation for Tomcat. This should be the first place you look for help when configuring and using Tomcat. The Tomcat User’s Guide can be found online at the Jakarta Tomcat Web site, http://jakarta.apache.org/tomcat.
Tomcat User Mailing List The Tomcat user mailing list is the best place to find community support for con- figuring and using Tomcat. This mailing list consists of most all the Tomcat developers and many of the current users of Tomcat. By posting a question on this mailing list, you can try to solicit information from the current Tomcat experts. You can subscribe to this mailing list by following the instructions on the Jakarta Mailing List page, http://jakarta.apache.org/site/mail.html. Be warned the Tomcat user mailing list generates a lot of traffic. A hundred or more emails a day is not uncommon; however, it is only an issue if you do not wish to deal with that volume of email. There are many benevolent people, which is obvious on the Tomcat user mailing list because of the unbelievable amount of questions they answer. An alternative to using the Tomcat user mailing list is to consult the online archives, which can be found using the same link.
Web Applications
A “Web Application”, not the commonly used “Web application” meaning any Web-savvy program, is the proper term for a complete Servlet and/or JSP project. Anytime you develop a JSP or Servlet, it is part of a larger Web Application. Each Web Application has its own unique configuration files and resources for use.
WEB APPLICATIONS 19
Book Support Site For the most current information and updates of this chapter’s walk-through guides, use the book support site, http://www.jspbook.com. Along with the latest versions of the walk-through guides, this site also contains a Frequently Asked Question (FAQ) section for questions relating to this book. Many of these questions answer problems relating to Tomcat configuration issues for various software environments. Additionally, the book support site is intended to provide a place that can deal with any unexpected issues occurring after publication.
These files and resources are defined by the JSP specification and Servlet specifi- cation and managed by your container. In summary they consist of:
- Configuration: Each Web Application includes a configuration file, web.xml. This configuration file customizes the resources of a Web Application in an efficient and structured fashion. Web Applications keep web.xml private from outside visitors and also provide a place for privately storing other custom configuration information. - Static Files and JSP: A Web Application’s primary purpose is to serve content on the World Wide Web. This content includes dynamic resources such as Servlets and JSP, but it also includes static resources such as HTML pages. A Web Application automati- cally manages JSP and static resources deployed in it. - Class Files and Packages: A Web Application also loads and manages custom Java code. For application-specific class files such as Servlets, a special location is designated from which a container can load and manage compiled code. Web Applications define a similar location for including Java Archive, JAR, files that contain packaged resources.
By the end of the chapter, most of these configuration files and resources will have been introduced and discussed, but an in-depth analysis of them cannot be attempted without understanding more about JSP and Servlets. As the book pro- gresses, all of the preceding will be fully defined and explored. But before dis- cussing any part of a Web Application, one must be created. Making a Web Application from scratch requires two things. First, a directory to hold all of the files for the Web Application is needed. The directory can be located anywhere on your local computer. For simplicity, create a directory named jspbook under the /webapps directory of your Tomcat installation. The webapps folder is Tomcat’s default location for storing Web Applications. To make this a Web Application, you also need to add a web.xml configuration file. To do this, go to the jspbook directory and create a subdirectory called WEB-INF. Inside the /WEB-INF directory create a file called web.xml. Save Listing 1-1 as the contents of web.xml.
Listing 1-1 web.xml Skeleton File
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" version="2.4"> </web-app>
20 SETTING UP A SERVLET AND JSP ENVIRONMENT
