Professional Apache Tomcat 6

Published by

Wiley Publishing, Inc.

10475 Crosspoint Boulevard

Indianapolis, IN 46256

www.wiley.com

Copyright © 2007 by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

ISBN: 978-0-471-75361-2

Library of Congress Cataloging-in-Publication Data

Chopra, Vivek.

Professional Apache Tomcat 6 / Vivek Chopra, Sing Li, and Jeff Genender.

p. cm.

Includes index.

ISBN 978-0-471-75361-2 (paper/website)

1. Apache Tomcat. 2. Web servers. 3. Web site development. 4. Internet programming. I. Li, Sing. II. Genender, Jeff M. III. Title.

TK5105.8885.A63C47 2007

005.7'1376—dc22

2007020134

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read.

For general information on our other products and services please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.

Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Wrox Programmer to Programmer, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

To Rebecca and Rohan, thanks for all your patience and support.

—Vivek

To my guiding light and spiritual support for the last two decades, Kim.

—Sing

To my wonderful wife, Nazarena, and my children, Madisyn, Weston, and Coleton. I could not have done this without you.

—Jeff

About the Authors

Vivek Chopra has more than 13 years of experience as a software architect, developer, and team lead and has worked in a number of Silicon Valley companies and startups. He writes actively on technology and is the author of more than half a dozen books on Java, open source software, XML, and Web services. Vivek has pending patents on Web service technologies, and has been a Java Community Process (JCP) member for the past three years. He also serves on the expert group for JSR 280 (XML API for Java ME).

Sing Li (who was bitten by the microcomputer bug in the late 1970s) has grown up with the Microprocessor Age. His first personal computer was a $99 do-it-yourself Netronics COSMIC ELF with 256 bytes of memory, mail-ordered from the back pages of Popular Electronics magazine. A 20-year industry veteran, Sing is a system developer, open source software contributor, and freelance writer specializing in Java technology, and embedded and distributed systems architecture. He regularly writes for several popular technical journals and e-zines, and is the creator of the “Internet Global Phone,” one of the very first Internet phones available. He has authored and co-authored a number of books across diverse technical disciplines including Geronimo, Tomcat, JSP, servlets, XML, Jini, media streaming, device drivers, and JXTA.

Jeff Genender has over 18 years of software architecture, team lead, and development experience in multiple industries. Jeff is an active committer and Project Management Committee (PMC) member for Apache Geronimo, and a committer on OpenTerracotta, OpenEJB, ServiceMix, and Mojo (Maven plugins). Jeff also serves as a member of the Java Community Process (JCP) expert group for JSR-313 (Java Platform, Enterprise Edition 6 [Java EE 6] Specification) as a representative of the Apache Software Foundation. Jeff is an open source evangelist and has successfully brought open source development efforts, initiatives, and success stories into a number of Global 2000 companies, saving these organizations millions in licensing costs.

Credits

Executive Editor

Bob Elliott

Development Editor

Sydney Jones

Technical Editors

Rupert Jones

Anne Horton

Copy Editor

Nancy Rapoport

Editorial Manager

Mary Beth Wakefield

Production Manager

Tim Tate

Vice President and Executive Group Publisher

Richard Swadley

Vice President and Executive Publisher

Joseph B. Wikert

Project Coordinator, Cover

Adrienne Martinez

Proofreader

Kathryn Duggan

Indexer

Johnna VanHoose Dinse

Anniversary Logo Design

Richard Pacifico

Introduction

Professional Apache Tomcat 6 is primarily targeted toward administrators and engineers responsible for Tomcat configuration, performance tuning, system security, or deployment architecture. This book doesn’t cover Web application development using Tomcat. A lot of other books, such as our Beginning JavaServer Pages (Wrox Press, ISBN 0-7645-7485-X), fulfill this need. Instead, this book focuses on its primary audience — i.e., Tomcat administrators — and tries to provide what this audience needs as best as it can.

This is the third edition in our Apache Tomcat series. Our first edition, Professional Apache Tomcat, covered Tomcat versions 3 and 4. The second edition, Professional Apache Tomcat 5, focused primarily on Tomcat 5. Since then, Tomcat has released a new edition, and hence the need for this book.

What’s Changed Since the Second Edition

Those of you who own a copy of our previous book will no doubt be wondering what’s changed in this one, and if it justifies purchasing an updated version.

Well, a lot has changed — and improved! There is a new specification (Servlet 2.5, JavaServer Pages 2.1) and a brand-new Tomcat version (Tomcat 6) implementing it. Tomcat 6 boasts of performance and memory optimizations, faster and more scalable Connectors, and an improved clustering implementation.

Other than updated content, you will find the following in the book:

Complete and updated coverage for Tomcat 6: This book focuses exclusively on the new Tomcat version.

Performance, Performance, Performance: Tomcat has finally come into its own, and is no longer a developer’s stepping stone to a more “industrial strength” server. Its use by a veritable Who’s Who of Fortune 500 companies, as well as highly trafficked Web sites, attests to this. The book reflects this status by adding a new chapter on performance tuning as well as coverage of the new, high-performance APR and NIO Connectors.

A new chapter on logging: Both Tomcat server logs as well as logging from Web applications. The chapter also covers log file management strategies and log analysis.

An enhanced chapter on managing and monitoring Tomcat using its JMX support.

A reworked chapter on clustering: Tomcat 6 introduces improvements in its clustering support, including a new clustering configuration.

A reworked chapter on securing Tomcat installations and Web applications.

Coverage of the Web server Connectors for Tomcat 6 — mod_proxy and mod_jk.

And many other topics!

We value your feedback, and have improved on areas that needed some changes in our second edition. You will find several of our original chapters rewritten based on your suggestions, with better organization and more content.

How to Use This Book

The best way to read a book is from cover to cover. We do recognize, however, that for a technical book of this nature, it is often not possible to do that. This is especially true if a busy administrator wants to refer to this book only for a particular urgent task at hand.

We have written this book to address both needs.

The chapters are structured so that they can be read one after another, with logically flowing content. The chapters are also independent to the degree possible, and include references to other sections in the book when it is necessary to have an understanding of some background material first.

This book is organized as follows:

Chapter 1, “Apache Tomcat,” provides an introduction to the Apache and Tomcat projects, their history, and information about the copyright licenses under which they can be used.

Chapter 2, “Web Applications: Servlets, JSPs, and More,” is a “10,000-foot overview” of Web technologies for administrators unfamiliar with them, including CGI, servlets, JSPs, JSP tag libraries, and MVC (Model-View-Controller) architecture.

Chapter 3, “Tomcat Installation,” details the installation of JVM and Tomcat on Windows and Unix/Linux systems, and offers troubleshooting tips.

Chapter 4, “Tomcat Architecture,” provides a conceptual background on components of the Tomcat 6 server architecture, including Connectors, Engines, Realms, Valves, Loggers, Hosts, and Contexts.

Chapter 5, “Basic Tomcat Configuration,” covers the configuration of the Tomcat server components introduced in Chapter 4.

Chapter 6, “Advanced Tomcat Features,” details advanced Tomcat configuration topics, such as access log administration, single sign-on across Web applications, request filtering, the Persistent Session Manager, and JavaMail session setup.

Chapter 7, “Web Application Configuration,” describes the structure of Web applications deployed in Tomcat, and their configurable elements.

Chapter 8, “Web Application Administration,” explains how these Web applications can be packaged, deployed, undeployed, and, in general, managed. There are three ways to do this in Tomcat: via HTTP commands, via a Web-based GUI, and through Ant scripts. This chapter describes all of them.

Chapter 9, “Class Loaders,” introduces Java class loaders and discusses their implications for Tomcat, including (but not limited to) security issues.

Chapter 10, “HTTP Connectors,” describes Tomcat’s internal HTTP protocol stack that enables it to work as a Web server. The chapter covers its configuration, as well as security and performance issues.

Chapter 11, “Tomcat and Apache HTTP Server,” covers the use of Apache as a Web server frontend for Tomcat using both Apache’s mod_proxy as well as the JK Connector. It also describes load-balancing configurations, as well as SSL setup.

Chapter 12, “Tomcat and IIS,” provides detailed coverage of the use of IIS as a Web server frontend for Tomcat.

Chapter 13, “JDBC Connectivity,” discusses JDBC-related issues in Tomcat, such as connection pooling, JNDI emulation, configuring a data source, and alternative JDBC configurations.

Chapter 14, “Tomcat Security,” deals with a wide range of security issues, from securing Tomcat installations to configuring security policies for Web applications that run on it.

Chapter 15, “Shared Tomcat Hosting,” will prove very useful to ISPs and their administrators, as it covers Tomcat installations in virtual hosting situations.

Chapter 16, “Monitoring and Managing Tomcat with JMX,” explores Tomcat’s Java Management Extension (JMX) support in detail.

Chapter 17, “Clustering,” covers Tomcat configurations for providing scalability and high availability to Web applications. This is a “must read” chapter for production deployments of Tomcat.

Chapter 18, “Embedded Tomcat,” details the mechanism for embedding Tomcat within custom applications.

Chapter 19, “Logging,” covers logging by the Tomcat server and Web applications, and techniques for log file management and log analysis.

Chapter 20, “Performance Testing,” explains how to develop a performance test plan for Web applications, and how to do performance test using the open-source JMeter framework.

Chapter 21, “Performance Tuning,” suggests where and how to look for the root cause when faced with specific Tomcat performance issues. This chapter also covers performance tuning tips and best practices for Tomcat 6.

Appendix A, “Tomcat and IDEs,” covers the support available for Tomcat in two popular open source IDEs: Eclipse and NetBeans.

Appendix B, “Apache Ant,” provides a tutorial introduction to Ant, as well as solutions for common tasks that system administrators need to do while developing build and deploy scripts. Apache Ant is used extensively in the book, both as a build/install tool, as well as a scripting engine. Ant is the standard tool used by administrators to automate repetitive tasks for Java-based Web development.

Conventions

To help you get the most from the text and keep track of what’s happening, we’ve used a number of conventions throughout the book.

Boxes like this one hold important, not-to-be forgotten information that is directly relevant to the surrounding text.

Tips, hints, tricks, and cautions regarding the current discussion are offset and placed in italics like this.

As for styles in the text:

New and defined terms are highlighted in italics when first introduced.

Keyboard strokes appear as follows: Ctrl+A.

Filenames, URLs, directories, utilities, parameters, and other code-related terms within the text are presented as follows: persistence.properties.

Code is presented in two different ways:

In code examples, we highlight new and important code with a gray background.

The gray highlighting is not used for code that's less important in the given context or for code that has been shown before.

Downloads for the Book

As you work through the examples in this book, you may choose either to type in all the code manually or to use the source code files that accompany the book. All of the source code used in this book is available for download at wrox.com/WileyCDA/WroxTitle/productCd-0471753612.html. Once at the site, simply locate the book’s title (either by using the Search box or by using one of the title lists) and click the Download Code link on the book’s detail page to obtain all the source code for the book.

Because many books have similar titles, you may find it easiest to search by ISBN; this book’s ISBN is 978-0-471-75361-2.

Once you download the code, just decompress it with your favorite compression tool. Alternately, you can go to the main Wrox code download page at wrox.com to see the code available for this book and all other Wrox books.

Errata

We made every effort to ensure that there are no errors in the text or in the code. However, no one is perfect, and mistakes do occur. If you find an error in one of our books, such as a spelling mistake or a faulty piece of code, we would be very grateful for your feedback. By sending us errata, you may save other readers hours of frustration, and you will be helping to provide even higher quality information.

To find the errata page for this book, go to wrox.com and locate the title using the Search box or one of the title lists. Then, on the book details page, click the Book Errata link. On this page, you can view all errata that has been submitted for this book and posted by Wrox editors. A complete book list, including links to each book’s errata, is also available at wrox.com/misc-pages/booklist.shtml.

If you don’t spot the error you found on the Book Errata page, go to wrox.com/contact/techsupport.shtml and complete the form that is provided to send us the error you have found. We’ll check the information and, if appropriate, post a message to the book’s errata page and fix the problem in a subsequent edition of the book.

p2p.wrox.com

For author and peer discussion, join the P2P forums at http://p2p.wrox.com. The forums are a Web-based system for you to post messages relating to Wrox books and related technologies and interact with other readers and technology users. The forums offer a subscription feature if you wish to be sent e-mail about topics of particular interest to you when new posts are made to the forums. Wrox authors, editors, other industry experts, and your fellow readers are present on these forums.

At the P2P Web site, you will find a number of different forums that will help you not only as you read this book, but also as you develop your own applications. To join the forums, just follow these steps:

1. Go to http://p2p.wrox.com and click the Register link.

2. Read the terms of use and click Agree.

3. Complete the required information to join as well as any optional information you wish to provide and click Submit.

4. You will receive an e-mail message with information describing how to verify your account and complete the joining process.

You can read messages in the forums without joining P2P, but in order to post your own messages, you must join.

Once you join, you can post new messages and respond to messages that other users post. You can read messages at any time on the Web. If you would like to have new messages from a particular forum e-mailed to you, click the Subscribe to this Forum icon by the forum name in the forum listing.

For more information about how to use the Wrox P2P, be sure to read the P2P FAQs for answers to questions about how the forum software works as well as many common questions specific to P2P and Wrox books. To read the FAQs, click the FAQ link on any P2P page.

Caveat

Finally, a caveat: Tomcat, like all active open-source projects, is a constantly evolving piece of software. This is usually good, because it keeps the software abreast of new technologies and improves existing ones. However, this can make the content in any related book outdated over time. This is especially true of new features that have been added in Tomcat 6. While we have made every effort possible to ensure that the book remains current, we would like to point you to the following additional resources:

Book Errata: Any changes in the book caused by new (or modified) Tomcat features will be posted in the book errata section of the Wrox Web site (wrox.com) under the Book List link.

Wrox P2P forum (http://p2p.wrox.com): The place where you can consult with the Wrox user community.

Tomcat User’s mailing list: Mailing list for Tomcat users. This is where questions relating to Tomcat’s usage and configuration should be posted. The archives for the list are at http://mail-archives.apache.org/mod_mbox/tomcat-user/ and http://marc.theaimsgroup.com/?l=tomcat-user, and directions for joining the list are at http://tomcat.apache.org/lists.html.

Tomcat Developer’s mailing list: Mailing list for developers of the Tomcat Servlet container. This is the place to track new developments in Tomcat. Do not post user questions on this list; use the Tomcat User’s mailing list instead. The archives for the list are at http://mail-archives.apache.org/mod_mbox/tomcat-dev/ and http://marc.theaimsgroup.com/?l=tomcat-dev, and directions for joining the list are at http://tomcat.apache.org/lists.html.

Yet another place to monitor Tomcat developments is the IRC channel http://tomcat.apache.org/irc.html.

The Apache bug database: Apache uses a Bugzilla-based system to track bugs (http://issues.apache.org/bugzilla/). This is where (using the Query Existing Bug Reports option in Bugzilla) you can verify whether the issue you are facing is configuration-related or a known Tomcat bug.

Chapter 1

Apache Tomcat

If you’ve written any Java servlets or JavaServer Pages (JSPs), chances are good that you’ve downloaded Tomcat. That is because Tomcat is a free, feature-complete Servlet container that developers of servlets and JSPs can use to run their code. Tomcat is used in Sun’s reference implementation of the Servlet Container, which means that Tomcat’s first goal is to be 100 percent compliant with the versions of the Servlet and JSP API specifications that it supports.

However, Tomcat is more than just a test server. Many corporations are using Tomcat in production environments because it has proven to be quite stable. These corporations range from Fortune 500 companies such as WalMart and General Motors to ISPs hosting multiple small-business Web sites. Tomcat is used in the real world to run everything from online photo albums (Webshots) to high performance financial Web applications (ETrade).

A list of Tomcat-powered Web sites is at http://wiki.apache.org/tomcat/PoweredBy.

Despite Tomcat’s popularity, it suffers from a common shortcoming among open source projects: lack of complete documentation. Some documentation is distributed with Tomcat (mirrored at http://tomcat.apache.org), and there’s an open source effort to write a Tomcat book (http://tomcatbook.sourceforge.net/). Even with these resources, however, there is a great need for additional material.

This book has been created not just to fill in some of the documentation holes, but to use the combined experience of the authors to help Java developers and system administrators make the most of the Tomcat product. Whether you’re trying to learn enough to just get started developing Web applications or want to understand the more arcane aspects of Tomcat configuration, you should find what you’re looking for within these pages.

The first two chapters are designed to provide newcomers with some basic background information that is prerequisite learning for subsequent chapters. If you’re a system administrator with no previous Java experience, we advise you to read these first two chapters, and likewise if you’re a Java developer who is new to Tomcat. If you’re well informed about Tomcat and Java, you’ll probably want to jump straight ahead to Chapter 3, although skimming this chapter and its successor is likely to add to your present understanding.

The following topics are discussed in this chapter:

The origins of the Tomcat server

The terms of Tomcat’s license and how it compares to other open source licenses

How Tomcat fits into the Java “big picture”

An overview of integrating Tomcat with Apache and other Web servers

Humble Beginnings: The Apache Project

One of the earliest Web servers was developed by Rob McCool at the National Center for Supercomputer Applications (NCSA), University of Illinois, Urbana-Champaign. This Web server was referred to colloquially as the NCSA project, or NCSA for short. By 1995, the NCSA server was quite popular, but its future was uncertain because the primary developer, McCool, had left NCSA the previous year. A group of developers got together and compiled all the NCSA bug fixes and enhancements they had found, and patched them into the NCSA code base. The developers released this new version in April 1995, and called it Apache, which was somewhat of an acronym for “A PAtCHy Web Server.”

Apache was readily accepted by the developer community from its earliest days, and less than a year after its release, it unseated NCSA to become the most used Web server in the world (measured by the total number of servers running Apache), a distinction that it has held ever since (according to Apache’s Web site). Incidentally, during the same period that Apache’s use was spreading, NCSA’s popularity was plummeting, and by 1999, NCSA was officially discontinued by its maintainers.

For more information on the history of Apache and its developers, see http://httpd.apache.org/ABOUT_APACHE.html.

Today, the Apache Web server is available on just about any major operating system (in addition to the source code download, Apache binaries are available for over a dozen operating systems). Apache can be found running on some of the largest server farms in the world, as well as on some of the smallest devices (including several hand-held devices). In UNIX data centers, Apache is as ubiquitous as air conditioning and UPS systems.

While Apache was originally a somewhat mangy collection of miscellaneous patches, today’s versions are rock-solid production quality servers. The only real competitor to Apache in terms of market share and feature set is Microsoft’s Internet Information Server (IIS), which is bundled free with certain versions of the Windows operating system. As of this writing, Apache’s market share is estimated at around 60 percent, with IIS at 30 percent (statistics courtesy of http://news.netcraft.com/archives/web_server_survey.html).

It is also worth noting that Apache has a reputation for being much more secure than Microsoft IIS. When new vulnerabilities are discovered in either server, the Apache developers fix Apache far faster than Microsoft fixes IIS.

The Apache Software Foundation

In 1999, the same folks who wrote the Apache server formed the Apache Software Foundation (ASF). The ASF is a nonprofit organization that was created to facilitate the development of open source software projects. Tomcat is developed under the auspices of the ASF. According to their Web site, the ASF accomplishes this goal by doing the following:

Providing a foundation for open, collaborative software development projects by supplying hardware, communication, and business infrastructure

Creating an independent legal entity to which companies and individuals can donate resources and be assured that those resources will be used for the public benefit

Providing a means for individual volunteers to be sheltered from legal suits directed at ASF projects

Protecting the Apache brand (as applied to its software products) from being abused by other organizations

In practice, the ASF does indeed sponsor a great many open source projects. While the best-known of these projects is likely the aforementioned Apache Web server, the ASF hosts many other well-respected and widely used projects, including such respected industry standards as the following:

Xerces: A Java/C++ XML parser with JAXP bindings

Ant: A Java-based build system (and much more)

Axis: A Java-based Web services implementation

The number of ASF-sponsored projects is growing fast. Visit www.apache.org to see the latest list.

Tomcat

The Tomcat project has its origins in the earliest days of Java’s servlet technology. Servlets are a certain type of Java application that plug into special Web servers, called Servlet containers (originally called Servlet engines). Sun created the first Servlet container, called the Java Web Server, which demonstrated the technology but wasn’t terribly robust. Meanwhile, the ASF folks created the JServ product, which was a Servlet engine that integrated with the Apache Web server.

In 1999, Sun donated its Servlet container code to the ASF, and the two projects were merged to create the Tomcat server. Today, Tomcat is used by Sun in its reference implementation (RI), which means that Tomcat’s first priority is to be fully compliant with the Servlet and JavaServer Pages (JSP) specifications published by Sun. This is discussed in more detail in Chapter 2.

The first version of Tomcat was the 3.x series, and it implemented the Servlet 2.2 and JSP 1.1 specifications. The Tomcat 3.x series was descended from the original code that Sun provided to the ASF in 1999.

In 2001, Tomcat 4.0 (code-named Catalina) was released. Catalina was a complete redesign of the Tomcat architecture, and built on a new code base. The Tomcat 4.x series was used in the RI of the Servlet 2.3 and JSP 1.2 specifications.

The latest version of Tomcat, Tomcat 6, implements the Servlet 2.5 and JSP 2.1 specifications. In addition, it boasts of an improved clustering implementation over the previous iteration (Tomcat 5.5).

Tomcat used to be a subproject under the Apache Jakarta project. The Jakarta project is an umbrella under which the ASF sponsors the development of many Java subprojects, such as JMeter, Log4j, and Struts. However, Tomcat has now been promoted to a top-level project.

Distributing Tomcat: The Apache License

Tomcat is open source software, and, as such, is free and freely distributable. However, if you have much experience in dealing with open source software, you’re probably aware that the terms of distribution can vary from project to project.

Most open source software is released with an accompanying license that states what may and may not be done to the software. At least 40 different open source licenses are in use, each of which has slightly different terms.

Providing a primer on all of the various open source licenses is beyond the scope of this chapter, but the license governing Tomcat is discussed here and compared with a few of the more popular open source licenses.

Tomcat is distributed under the Apache License, which is listed at apache.org/licenses. The key points of this license state the following:

The Apache License must be included with any redistribution of Tomcat’s source code or binaries.

Any documentation included with redistribution must give a nod to the ASF.

Products derived from the Tomcat source code can’t use the terms “Tomcat,” “The Jakarta Project,” “Apache,” or “Apache Software Foundation” to endorse or promote their software without prior written permission from the ASF.

Tomcat has no warranty of any kind.

However, through omission, the license contains the following additional implicit permissions:

Tomcat can be used by any entity (commercial or noncommercial) for free without limitation.

Those that make modifications to Tomcat and distribute their modified version do not have to include the source code of their modifications.

Those who make modifications to Tomcat do not have to donate their modifications to the ASF.

Thus, you’re free to deploy Tomcat in your company in any way you see fit. It can be your production Web server or your test Servlet container used by your developers. You can also redistribute Tomcat with any commercial application that you may be selling, provided that you include the license and give credit to the ASF. You can even use the Tomcat source code as the foundation for your own commercial product.

Comparison with Other Licenses

Among the previously mentioned and rather large group of other open source licenses, two licenses are particularly popular at the present time: the GNU General Public License (GPL) and the GNU Lesser General Public License (LGPL). Let’s take a look at how each of these licenses compares to the Apache License.

GPL

The GNU Project created and actively evangelizes the GPL. The GNU Project is somewhat similar to the ASF, with the exception that the GNU Project would like all of the non-free (that is, closed source or proprietary) software in the world to become free. The ASF has no such (stated) desire and simply wants to provide free software.

Free software can mean one of two entirely different things: software that doesn’t cost anything and software that can be freely copied, distributed, and modified by anyone (thus, the source code is included or is easily accessible). Such software can be distributed either free or for a fee. A simpler way to explain the difference between these two types of free is to compare “free,” as in “free beer,” and “free,” as in “free speech.” The GNU Project’s goal is to create free software of the latter category. All uses of the phrase “free software” in the remainder of this section use this definition.

The differences between the Apache License and the GPL thus mirror the distinct philosophies of the two organizations. Specifically, the GPL has the following key differences from the Apache License:

No “non-free” software may contain GPL-licensed products or use GPL-licensed source code. If non-free software is found to contain GPL-licensed binaries or code, it must remove such elements or become free software itself.

All modifications made to GPL-licensed products must be released as free software if the modifications are also publicly released.

These two differences have huge implications for commercial enterprises. If Tomcat were licensed under the GPL, any product that contained Tomcat would also have to be free software.

Furthermore, while the Apache License permits an organization to make modifications to Tomcat and sell it under a different name as a closed source product, the GPL would not allow any such act to occur; the new derived product would also have to be released as free software.

LGPL

The GNU Lesser General Public License (LGPL) is similar to the GPL, with one major difference: Non-free software may contain LGPL-licensed products. The LGPL license is commonly referred to as the “library” GPL because it is intended primarily for software libraries that are themselves free software, but whose authors want them to be available for use by companies who produce non-free software.

If Tomcat were licensed under the LGPL, it could be embedded in non-free software, but Tomcat could not itself be modified and released as a non-free software product.

For more information on the GPL and LGPL licenses, see www.gnu.org.

Other Licenses

Understanding and comparing open source licenses can be a rather complex task. The preceding explanations are an attempt to simplify the issues. For more detailed information on these and other licenses, the following two resources can help you:

The Open Source Initiative (OSI) maintains a database of open source licenses. Visit them at www.opensource.org.

The GNU Project has an extensive comparison of open source licenses with the GPL license. See it at www.gnu.org/licenses/license-list.html.

The Big Picture: Java EE

As a Servlet container, Tomcat is a key component of a larger set of standards collectively referred to as the Java Enterprise Edition (Java EE) platform. The Java EE standard defines a group of Java-based APIs that are suited to creating Web applications for enterprises (that is, large companies). To be sure, companies of any size can take advantage of Java EE, but many Java EE technologies are especially designed to solve the problems associated with the creation of large software systems.

Java EE is built on the Java Standard Edition (Java SE), which includes the Java binaries (such as the JVM and bytecode compiler), as well as the core Java code libraries. Java EE depends on Java SE to function. Both the Java SE and Java EE can be obtained from http://java.sun.com. Both Java SE and Java EE are referred to as platforms, because they provide core functionality that acts as a sort of platform or foundation upon which applications can be built.

Since the middle of 2005, Sun has been re-branding some of the Java platform names. Java Enterprise Edition, previously called J2EE, is now called Java EE. Java Standard Edition, previously called J2SE, is now Java SE. Similarly, the mobile edition (previously J2ME) has been renamed to Java ME.

Java APIs

As mentioned, Java EE is a standardized collection of Java APIs. The term API (or application programming interface) is used by software developers in general to describe services made available to applications by an underlying service provider (such as an operating system). In the Java world, this term is used to describe many of the services that the Java Virtual Machine (JVM) and its code libraries make available to Java programs.

An important characteristic of APIs is that they are separated from the services that provide them. In other words, an API is a kind of technical contract defining the functionality that two parties must provide: a service provider (often called an implementation) and an application. If both parties adhere to the contract, an API is pluggable (that is, a new service provider can be plugged into the relationship). Of course, if a service provider fails to conform to the contract, the applications that use the API will fail to function properly.

The Java Community Process

APIs in the Java world are created and modified by a standards body known as the Java Community Process (JCP). The JCP is composed of hundreds of Java Specification Requests (JSRs). Each JSR is a request to either change an existing aspect of Java (including its APIs) or introduce a new API or feature to Java. New JSRs can be submitted by a member of the JCP. Anyone can become a member of the JCP and, notably, individuals may do so at no cost (organizations pay a nominal fee). Once submitted, the JCP Executive Committee must approve the JSR. The Executive Committee consists of JCP members who have been elected to three-year terms in an annual election.

When a JSR is approved, the submitter becomes the Spec Lead. The Spec Lead forms an Expert Group composed of JCP members who assist the Spec Lead in creating a specification detailing the change or addition to the Java language. The Expert Group shepherds the specification along through various review processes (to other JCP members and to the public) until, finally, the JSR is judged completed and is approved by the Executive Committee. If a JSR results in an API, the Expert Group must also provide a reference implementation of the API (discussed earlier in this chapter in the context of Tomcat) and a technology compatibility kit (TCK) that other implementers can use to verify compatibility with the API.

Thus, via the JCP, any Java developer can influence the Java platforms, by submitting a JSR, becoming a member of an existing JSR’s Expert Group, or by simply giving feedback to JSR Expert Groups. While not the first attempt to create a technology standards body, the JCP is probably the world’s best combination of accessibility and influence. As a contrast, the influential World Wide Web Consortium (W3C) standards body charges almost $6,000 for individuals to join. Visit the JCP at www.jcp.org.

The Java EE APIs

As mentioned, the Java EE 5 platform consists of many individual APIs. The Servlet and JSP APIs are two of these. The following table describes some of the other Java EE APIs, and a complete list can be found at http://java.sun.com/javaee/technologies/.

Java EE API
Description

Enterprise JavaBeans (EJB)
Provides a mechanism that is intended to make it easy for Java developers to use advanced features in their components, such as remote method invocation (RMI), object/relational mapping (that is, saving Java objects to a relational database), distributed transactions across multiple data sources, statefulness, and so on.

Java Message Service (JMS)
Provides high-performance asynchronous messaging. Among other things, it enables Java EE applications to communicate with non-Java systems on top of various transports.

Web service APIs
A set of APIs for Web services and XML processing. These include JAX-WS, JAX-RPC, JAXB, SAAJ, and StAX.

Java Management Extensions (JMX)
Standardizes a mechanism for interactively monitoring and managing applications at runtime.

Java Transaction API (JTA)
JTA enables applications to gracefully handle failures in one or more of their components by establishing transactions. During a transaction, multiple events can occur, and if any one of them fails, the state of the application can be rolled back to the way it was before the transaction began. JTA provides the functionality of database-transactions technology across an entire distributed application.

JavaMail
Provides the capability to send and receive e-mail via the industry-standard POP/SMTP/IMAP protocols.

In addition to the Java EE–specific APIs, Java EE applications also rely heavily on Java SE APIs. In fact, over the years, several of the Java EE APIs have been migrated to the Java SE platform. Two such APIs are the Java Naming and Directory Interface (JNDI), used for interfacing with LDAP-compliant directories (and much more), and the Java API for XML Processing (JAXP), which is used for parsing and transforming XML (using XSLT). The vast collection of Java EE and Java SE APIs form a platform for enterprise software development unparalleled in the industry.

Java EE Application Servers

As mentioned, an API simply defines services that a service provider (i.e., the implementation) makes available to applications. Thus, an API without an implementation is useless. While the JCP does provide RIs of all the APIs, using them piecemeal is not the most efficient way to build applications. Enter the Java EE application server.

Various third parties provide commercial-grade implementations of the Java EE APIs. These implementations are typically packaged as a Java EE application server. Whereas Tomcat provides an implementation of the Servlet and JSP APIs (and is thus called a Servlet container), application servers provide a superset of Tomcat’s functionality: the Servlet and JSP APIs plus all the other Java EE APIs, and some Java SE APIs (such as JNDI).

Dozens of vendors have created Java EE–compatible application servers. Being called “Java EE–compliant” means that a vendor of an application server has paid Sun a considerable sum, and has passed various compatibility tests. Such vendors are said to be Java EE licensees.

The two most widely used commercial Java EE application servers are Websphere from IBM and Weblogic from BEA. Other than these, there are a number of open source implementations too, such as the following:

JBoss (www.jboss.org)

JOnAS (jonas.objectweb.org)

Geronimo (geronimo.apache.org)

Glassfish (glassfish.dev.java.net)

“Agree on Standards, Compete on Implementation”

Developers who use the Java EE APIs can use a Java EE–compatible application server from any vendor, and it is guaranteed to work with their applications. This flexibility is intended to help customers avoid vendor lock-in problems, enabling users to enjoy the benefits of a competitive marketplace. The Java slogan along these lines is “Agree on standards, compete on implementation,” meaning that the vendors all cooperate in establishing universal Java EE standards (through participation in the JCP) and then work hard to create the best application server implementation of those standards.

That’s the theory, at least. In reality, this happy vision of vendor neutrality and open standards is slightly marred by at least two factors. First, each application server is likely to have its own eccentricities and bugs. This leads to a popular variation on the famous “Write Once, Run Anywhere” Java slogan: “Write Once, Test Everywhere.” Second, vendors are rarely altruistic. Each application server typically includes a series of powerful features that are outside the scope of the Java EE APIs. Once developers take advantage of these features, their application is no longer portable, resulting in vendor lock-in. Developers must, therefore, be vigilant to maintain their application’s portability, if such a capability is desirable.

Tomcat and Application Servers

Up to this point, Tomcat has been referred to as an implementation of the Servlet/JSP APIs (i.e., a Servlet container). However, Tomcat is more than this. It also provides an implementation of the JNDI and JMX APIs. However, Tomcat is not a complete Java EE application server; it doesn’t provide support for even a majority of the Java EE APIs.

Interestingly, many application servers actually use Tomcat as their implementation of the Servlet and JSP APIs. Because Tomcat permits developers to embed Tomcat in their applications with only a one-line acknowledgment, many commercial application servers quietly rely on Tomcat without emphasizing that fact. The JBoss and JOnAS application servers mentioned previously make explicit use of Tomcat.

Developers seeking to create Java Web applications that utilize the Servlet, JSP, JNDI, and JMX APIs will find Tomcat an excellent solution. However, those seeking support for additional APIs will probably be better served to either find an application server, or use Tomcat in addition to an application server. A third option is to find an implementation of the individual Java EE APIs required and use them in conjunction with Tomcat. This piecemeal approach is perfectly valid, although integration problems may manifest themselves.

Do you always need a full-fledged Java EE application server to develop enterprise applications? The short answer is “It depends on your requirements.” An increasing number of Web sites eschew the traditional Java EE technologies — especially EJB — and develop fairly complex applications with “lightweight” and often open source components. These typically use an application framework such as Struts or Spring, or an object-relational mapping framework such as Hibernate — all running in a state-of-the-art Servlet container, i.e., Tomcat!

Tomcat and Web Servers

Tomcat’s purpose is to provide standards-compliant support for Servlets and JSPs. The purpose of Servlets and JSPs is to generate Web content such as HTML files or GIF files on demand, using changing data. Web content that is generated on demand is said to be dynamic. Conversely, Web content that never changes and is served up as is, is called static. Web applications commonly include a great deal of static content, such as images or Cascading Style Sheets (CSS).

While Tomcat is capable of serving dynamic and static content, many production deployments use a native Web server, such as Apache HTTP Server or IIS, to handle the static content. There are many reasons for choosing to do this, some of which relate to performance and others relate to support of legacy code. Chapters 11 and 12 address these issues in greater detail.

Recognizing that Tomcat could enjoy a synergistic relationship with conventional Web servers, the earliest versions of Tomcat included a “Connector” that enabled a Tomcat and Apache Web server to work together. In such a relationship, Apache receives all of the HTTP requests made to the Web application. Apache then recognizes which requests are intended for Servlets/JSPs, and passes these requests to Tomcat. Tomcat fulfills the request and passes the response back to Apache, which then returns the response to the requestor.

The Apache Connector was initially crucial to the Tomcat 3.x series, because Tomcat’s support for both static content and its implementation of the HTTP protocol were somewhat limited.

Starting with the 4.x series, Tomcat featured a much more complete implementation of HTTP and better support for serving up static content, and should by itself be sufficient for most deployments.

If you’re not using either Apache or IIS or any other Web server officially supported by Tomcat, then don’t give up hope entirely. It is still very possible to integrate Tomcat with other Web servers, even one that resides on the same machine. If you wish to run them on the same machine for instance, all you have to do is to set up Tomcat and the Web server to run on different network ports. You then can then design your Web application to request its static resources from the Web server, and have Tomcat handle the requests for dynamic content.

In many situations it might be simpler to just use Tomcat’s own Web server implementation. Tomcat has an “HTTP Connector” — i.e., a component that implements an HTTP server. More on this, including when it makes sense to use this, and when a native Web server is a better choice, is explained in Chapter 10.

Summary

To conclude this chapter overview of Tomcat, let’s review some of the key points we discussed:

The Apache Software Foundation (ASF) is a nonprofit organization created to provide the world with quality open source software.

The ASF maintains an extensive collection of open source projects. Many of the ASF’s Java projects are collected under the umbrella of a parent project called Jakarta.

Tomcat started as a subproject of the Jakarta project, but now is independent of it.

Tomcat can be freely used in any organization. It can be freely redistributed in any commercial project so long as its license is also included with the redistribution and proper recognition is given.

Java EE is a series of Java APIs designed to facilitate the creation of complex enterprise applications. Java EE–compatible application servers provide implementations of the Java EE APIs.

Tomcat is a Java EE–compliant Servlet container and is the official reference implementation for the Java Servlet and JavaServer Pages APIs. Tomcat also includes implementations of the JNDI and JMX APIs, but not the rest of the Java EE APIs, and is not, thus, a complete Java EE application server.

While Tomcat can function as a Web server, it can also be integrated with other Web servers.

Tomcat has special support for integrating with the Apache, IIS, and Netscape Enterprise Server (NES) servers, among others.

This chapter has provided a basic introduction to Tomcat. Chapter 2 describes what Tomcat-served Web applications look like and what files they comprise. It also provides a quick background to Web applications, which should be useful for administrators who do not have a background in Java technologies.

Chapter 2

Web Applications: Servlets, JSPs, and More

Tomcat administrators do not need to be Java or Web developers; however, an understanding of the technologies involved is useful. Toward that objective, this chapter provides an introduction to the following technologies for building dynamic Web sites:

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!