Servlets and JavaServer Pages

core servlets and javaserver pages advanced technologies and relationship between java servlets and javaserver pages (jsp), core servlets and javaserver pages pdf free download
LexiWills Profile Pic
LexiWills,United Kingdom,Professional
Published Date:31-07-2017
Your Website URL(Optional)
Comment
falkner.fm.qxd 8/21/03 5:16 PM Page iii TM Servlets and JavaServer Pages TM The J2EE Technology Web Tier Jayson Falkner Kevin Jones Boston • San Francisco • New York • Toronto • Montreal London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico Cityfalkner.fm.qxd 8/21/03 5:16 PM Page vii Contents Preface xv 1 Setting Up a Servlet and JSP Environment 1 A Quick History of Web Development 1 CGI 2 Java Servlets 4 Containers 4 Getting Java Support 6 Downloading the Java 2 Standard Edition 1.4 6 Installing J2SE 1.4 on Microsoft Windows 7 Installing J2SE 1.4 on Linux Distributions 7 Tomcat 9 Configuring Tomcat 17 Web Applications 19 /WEB-INF and web.xml 22 Java Classes and Source Files 24 Java Archive (JAR) Files 25 Web Application Resource (WAR) Files 25 Ant 26 What Does Ant Do? 26 Installing Ant 27 Using Ant 27 Summary 29 2 Java Servlets 31 What Servlets Are and Why You Would Want to Use Them 32 Web Applications 32 Servlets and HTTP Servlets 32 Filters 33 Security 33 Internationalization 33 Servlet Life Cycle 33 Servlets for the World Wide Web 35 Requests, Responses, and Headers 36 viifalkner.fm.qxd 8/21/03 5:16 PM Page viii GET and POST 39 HTTP Response Codes 40 Coding a HttpServlet 41 Deploying a Servlet 43 Web Application Deployment Descriptor Structure 46 Servlet Configuration 47 Limitations of Configuration: web.xml Additions 50 Client/Server Servlet Programming 51 HttpServletRequest and HttpServletResponse 51 HttpServletResponse 52 HttpServletRequest 64 ServletContext 92 Initial Web Application Parameters 92 Servlet Event Listeners 102 Summary 106 3 JavaServer Pages 109 JSP 2.0 Specification 110 JSP 110 JavaBeans 110 Custom Tags and JSP Fragments 110 Expression Language 110 JSP Life Cycle 111 The Difference Between Servlets and JSP 112 JSP Syntax and Semantics 116 Elements and Template Data 116 Two Types of Syntax 116 Scripting Elements 117 Directives 126 JSP Configuration 133 Standard JSP Actions 136 White Space Preservation 145 Attributes 147 Comments 147 Quoting and Escape Characters 149 Implicit Objects 150 pageContext 153 out 154 config 157 page 159 JSP in XML Syntax 159 XML Rules 162 JSP Documents 162 Summary 165 viii CONTENTSfalkner.fm.qxd 8/21/03 5:16 PM Page ix 4 Exception Handling 167 Errors and Exceptions 168 Throwing Exceptions 169 Try, Catch, Finally 172 JSP and Servlet Exceptions 174 Web Application Exception Handling 176 Micro-Managing Exceptions 176 Macro-Managing Exceptions 181 Web Application Error Pages 182 Logging 191 The Problem with System.out.println() 192 JDK 1.4 Logging Versus Log4j 193 Using the java.util.logging Package 193 Handlers 196 Loggers 199 Logging and Performance 208 A General Philosophy for Exception Handling and Logging 208 Summary 210 5 JavaBeans and the JSP Expression Language 213 JavaBeans 214 Get and Set Methods 214 Why Get and Set Methods? 215 Servlets, JSP, and JavaBeans 217 jsp:useBean/ 217 jsp:getProperty/ and jsp:setProperty/ 221 Good Use of JavaBeans 225 Design Patterns and JavaBeans 226 JSP. 2.0 Expression Language 227 Disabling the EL 227 JSP EL Syntax 228 Reserved Words 230 EL Functions 230 Good Uses of the JSP EL 231 Summary 234 6 JavaServer Pages Standard Tag Library 235 JSTL 1.0 Specification 235 Why You Should Use the JSTL 237 Installing the JSTL 237 JSTL Expression Language 238 Twin Libraries 239 Core Tags 239 General-Purpose Tags 239 CONTENTS ixfalkner.fm.qxd 8/21/03 5:16 PM Page x Iteration 243 Conditionals 247 URL Manipulation 250 I18N-Capable Text Formatting 255 XML Manipulation 255 SQL Tags 256 Justification for Skipping the SQL Tags 256 Summary 258 7 Custom Tag Libraries 259 Why Custom Tags? 260 Tag Library Basics 261 How Are Tags Being Used? 262 New and Old Custom Tags 265 Tag Library Descriptors (TLDs) 265 What Is a Tag Library Descriptor? 266 Using a Tag Library Descriptor 267 Simple, JSP 2.0 Custom Tags 271 SimpleTag Interface 272 Attributes 275 Body Evaluation and Iteration 285 .tag Files 288 Cooperating Tags 299 Classic JSP Tag Handlers 300 Basic Tags 300 Coding a BasicTag 303 Reusing Tags 308 TryCatchFinally Interface 310 Cooperating Tags 311 Mixing New Tags with Classic Tags 313 Iteration Tags 315 Body Tags 321 Tag Scripting Variables 324 Tag Library Listeners 328 Validation 329 Summary 8Filters 333 Introducing Filters 334 What Is a Filter? 334 The Filter Life Cycle 335 Coding a Simple Filter 336 Wrappers 352 Request Wrapping 353 Response Wrapping 357 x CONTENTSfalkner.fm.qxd 8/21/03 5:16 PM Page xi Filters That Provide JSP-Replacing Functionality 387 Summary 388 9 Managing State in a Web Application 389 HTTP and Session State 390 Using an ID to Identify Clients 391 javax.servlet.http.HttpSession 392 Cookies 395 Initializing Session Resources 406 Persistent State 411 Session Smearing 412 Sharing State Information via a Database 413 State and Thread Safety 414 Synchronizing 416 Protecting Servlet State 416 javax.servlet.SingleThreadModel 420 Protecting Session and Application State 421 Summary 422 10Security 423 What Do We Mean by Security? 424 Declarative Security 425 Role-Based Security 426 Configuring Realms 430 The Big Picture 432 Configuring Basic or Digest Authentication 437 Custom Form-Based Authentication 438 Programmatic Security in a Servlet/JSP 440 Secure, Encrypted Communication 443 Specifying HTTPS 448 How Secure Is Security? 452 Encryption and Compression and Caching 453 Summary 455 11 Design Patterns 457 Why Use a Design Pattern? 458 Common Design Patterns 458 Model 1 459 Model 2 472 Good Model 2 Implementation 487 Jakarta Struts 490 Installing Struts 491 Struts Control Servlet 494 Actions 496 CONTENTS xifalkner.fm.qxd 8/21/03 5:16 PM Page xii Using Struts 507 1 Model 1 ⁄2 507 Abstracting DHTML via Custom Tags 510 Why Abstract DHTML with Custom Tags? 510 Coding DHTML Widget Custom Actions 511 Summary 512 12Internationalization 513 Content Encoding 514 ISO-8859-1 514 Unicode 517 Working with Non-ISO-8859-1 Encoding 518 i18n Implementation Techniques 523 Language Detection 524 Multiple Pages 527 Content Abstraction 531 Number and Date Formatting 539 i18n Numbers and Dates at Runtime 540 Using DateFormat, NumberFormat, and MessageFormat 543 JSTL Number and Date Formatting Tags 549 Summary 550 13 Multi-Client Support 553 Who Should Read This Chapter 554 Separating Format from Content 555 Implementing Multi-Client Support 557 Templates 558 Transformations 563 Solving Multi-Client Problems 566 Creating a Multi-Client Interface 566 Non-Text Formats 586 Summary 588 14 Database Connectivity 591 What Is a Database? 592 SQL 594 CRUD 597 JDBC 605 javax.sql.DataSource 606 java.sql.Connection and java.sql.Statement 614 java.sql.ResultSet 617 A Simple JDBC-Based Application 624 Using JDBC Optimally 632 Connection Pooling 633 Optimized Statements 634 Database Administrators Are Expected to Know a Lot 638 xii CONTENTSfalkner.fm.qxd 8/21/03 5:16 PM Page xiii JDBC Web Application Design Patterns 638 Data Access Object Design Pattern 640 Summary 649 15 Building a Complete Web Application 651 Designing a Web Application 652 Physical Implementation 654 Distributing the Workload: Dividing Up Who Does What 656 Practical Use of Web Application Labor Division 657 Implementing Database Support: Creating a Database and Using JDBC 658 Database Physical Design 658 Interfacing Without SQL 661 Implementing Business Logic: Filters and the Model 2 Design Pattern 662 Coding Model 2 Logic Classes and Populating Request-Scope Variables 664 Dealing with Overly Complex Logic Components 687 Implementing Presentation Logic: JSP, Multi-Client Design, and Internationalization 687 Building a Simple Presentation Page 688 Creating the Other Presentation Pages 696 Localized Content 703 (in Japanese) 709 Finishing the Site 711 Site-Wide Error Handling 712 Adding Security 715 Link Tracking 717 Caching and Compression 721 Adding the Egg 726 Summary 733 Index 735 CONTENTS xiiifalkner.ch1.qxd 8/21/03 4:42 PM Page 1 Chapter 1 Setting Up a Servlet and JSP Environment Before 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 1falkner.ch1.qxd 8/21/03 4:42 PM Page 2 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 Web Server CGI Process Request Request CGI Process Request CGI Process Figure 1-1 CGI Life Cycle 2 SETTING UP A SERVLET AND JSP ENVIRONMENTfalkner.ch1.qxd 8/21/03 4:42 PM Page 3 shut it down when there is no longer a need for a Web server. Starting and stopping a Web server is like the single-phase life cycle of CGI, and it was a very noticeable problem. CGI did not scale well and would often bring a Web server to a halt. Even with poor performance by today’s standards, CGI was a revolu- tionary step in the evolution of server-side programming. Developers had a cross platform method of creating dynamic content using most any of their favorite scripting and programming languages. This popularity sparked second-generation CGI implementations that attempted to counter the per- formance problems of original CGI, namely FastCGI. While the single phase life cycle still existed, CGI implementations improved efficiency by pooling resources for requests. This eliminated the need to create and destroy processes for every request and made CGI a much more practical solution. Figure 1-2 shows the improved implementation of CGI. Instead of one request per a process, a pool of processes is kept that continuously handle requests. If one process finishes handling a request, it is kept and used to manage the next incoming request rather than start a new process for each request. This same pooling design can still be found in many of today’s CGI imple- mentations. Using pooling techniques, CGI is a viable solution for creating dynamic content with a Web server, but it is still not without problems. Most notable is the difficulty in sharing resources such as a common logging utility or server-side object between different requests. Solving these problems involves using creative fixes that work with the specific CGI and are custom-made for individual projects. For serious Web applications, a better solution, preferably one that addresses the problems of CGI, was required. CGI Web Server CGI Process Pool CGI Process Request Request CGI Process Request CGI Process Figure 1-2 Pooled CGI Resources A QUICK HISTORY OF WEB DEVELOPMENT 3falkner.ch1.qxd 8/21/03 4:42 PM Page 4 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-3 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- 1 bined make up the official “Web Tier” for the Java 2 Enterprise Edition, J2EE . 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 Web Server Process Servlet Request Request Servlet Request Servlet Figure 1-3 Servlet Web Server Diagram 1. 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. 4 SETTING UP A SERVLET AND JSP ENVIRONMENTfalkner.ch1.qxd 8/21/03 4:42 PM Page 5 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 Web Server Container CGI Process Request Request CGI Process Request CGI Process Figure 1-4 Container Process CONTAINERS 5falkner.ch1.qxd 8/21/03 4:42 PM Page 6 the reference implementation JSP 2.0 and Servlet 2.4 container. If you have a pre- viously installed container, make sure it supports the correct version of Servlets and JSP; older containers do not support some of the features of JSP 2.0 and Servlet 2.4 specifications. In this book specifically, all examples were created and tested using the reference implementation container, Tomcat. Version 5 of Tomcat is the reference implementation for both Servlets 2.4 and JSP 2.0. If you need to install a compatible container, take the time to now download and install Tomcat 5. Getting Java Support Servlets and JavaServer Pages, also meaning all containers, rely on the Java pro- gramming language. In the case of Servlets, the code is nothing more than a Java class that implements the appropriate interface(s). Compiling a Servlet is iden- tical to compiling a Java class. JSP is slightly more abstract. JSP, is compiled and used exactly like a Servlet, but the process is almost always done automatically, without a JSP developer noticing. When authoring a JSP, a developer uses a com- bination of markup and code to make a page that usually resembles an HTML or XML document. This page is compiled into a class file by the Servlet container and automatically loaded. The official Java platform is designed, owned, and managed by Sun Microsystems. Unlike most other programming languages, Java is not designed for you to compile to platform-specific instructions. Instead Java is compiled down to byte code that gets interpreted by the computer running your Java program. This means a Java program developed and compiled on one computer will run on any other computer with Java support; Servlets and JSP can be com- piled and run on most any operating system. This includes most all the Windows, Linux, and Macintosh operating systems. This book assumes you are installing a JSP environment on one of these systems and instructions are provided for installation on each. Downloading the Java 2 Standard Edition 1.4 Java 2 Standard Edition 1.4 (J2SE 1.4) support is required for code examples in this book. Sun Microsystems provides a free reference implementation of Java 1.4 online. Unless you are using Macintosh OS X, go to http://java.sun.com/ j2se/1.4/ and download the latest Java distribution for your computer. Macintosh OS X has proprietary support for Java 2. If you are running OS X, no additional downloads are needed. 6 SETTING UP A SERVLET AND JSP ENVIRONMENTfalkner.ch1.qxd 8/21/03 4:42 PM Page 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- rd 2 mation, refer to Thinking In Java, 3 Edition , 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.4 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 2. A free copy of the book can be found online, http://www.mindview.net/Books/TIJ/. GETTING JAVA SUPPORT 7falkner.ch1.qxd 8/21/03 4:42 PM Page 8 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.4 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 8 SETTING UP A SERVLET AND JSP ENVIRONMENTfalkner.ch1.qxd 8/21/03 4:42 PM Page 9 For Non-x86 Users: Compiling Java for Yourself It is possible you are either an advanced user who dislikes non-optimized code or that you do not have an x86 microprocessor. Both of these cases are largely outside the scope of this book, but a quick pointer should get you well on your way if that is what you seek. The “official” Java Linux code is maintained at Blackdown Linux, http://www.blackdown.org. Visit Blackdown Linux if you need the source code to either optimize your Java distribution or compile it for a different architecture. Tomcat Tomcat, the reference implementation of Servlets and JSP, is part of the open source Apache Jakarta project and is freely available for download from 3 http://jakarta.apache.org/tomcat . Tomcat can be run on Windows, Linux, Macintosh, Solaris, and most any of the other Unix distributions. You can use Tomcat both commercially and non-commercially as specified by the Apache Software Foundation License. The next few sections provide a walk-through for installing Tomcat on Windows, Linux distributions, and Macintosh OS X. If needed, follow the appro- priate section to get Tomcat correctly set up for later examples. Installing Jakarta Tomcat 5 on Windows The Tomcat installation for Windows greatly resembles installing any other piece of Windows software. The process involves downloading the Tomcat installation executable file and running it to launch the Windows installation wizard. After a few simple clicks, the wizard will have set up Tomcat to work with your Windows distribution. If you have not done so already, download the Windows executable file for the Tomcat installation. You can find it at the following URL, http://jakarta. apache.org/builds/jakarta-tomcat/release/. Simply follow the links to the latest Tomcat 5 Windows executable file—as of this writing, the 5.0.2 beta release of Tomcat is at http://jakarta.apache.org/builds/jakarta-tomcat/release/ v5.0.2-alpha/bin/jakarta-tomcat-5.0.2.exe. After downloading the exe- cutable, double-click on it to start the installation wizard. A screen similar to 3. This part of the book is perhaps the most important. If for any reason you are having trouble installing Tomcat, please consult the book support site, http://www.jspbook.com, for a complete, up- to-date Tomcat 5 installation guide. GETTING JAVA SUPPORT 9falkner.ch1.qxd 8/21/03 4:42 PM Page 10 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 10 SETTING UP A SERVLET AND JSP ENVIRONMENTfalkner.ch1.qxd 8/21/03 4:42 PM Page 11 Figure 1-7 Installation Wizard Choosing Tomcat’s Components Figure 1-8 Installation Wizard for Installing Tomcat GETTING JAVA SUPPORT 11falkner.ch1.qxd 8/21/03 4:42 PM Page 12 Figure 1-9 Installation Wizard for Configuring Tomcat Figure 1-10 Installation Wizard Showing the Location of the Current JVM 12 SETTING UP A SERVLET AND JSP ENVIRONMENT

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.