Back to description
If you’ve written any Java servlets or JavaServer Pages (JSPs), chances are good that you’ve downloaded Tomcat.... more
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 also the reference implementation of a 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).
Note
A list of Tomcat-powered Web sites is at http://wiki.apache.org/tomcat/PoweredBy.
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.
http://tomcat.apache.org
http://tomcatbook.sourceforge.net/
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
... less
Tomcat administrators do not need to be Java or web developers; however, an understanding of the technologies involved... 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:
CGI scripts
Server-based Java technologies: servlets, JSPs, and tag libraries
MVC architecture, and implementations (Struts, for example)
Web applications built using the preceding technologies
The previous two chapters provided a background to Tomcat: a brief history, Tomcat licensing details,... more
The previous two chapters provided a background to Tomcat: a brief history, Tomcat licensing details, an overview of where Servlet containers such as Tomcat fit in the enterprise Java (Java EE) stack, and an introduction to Web application technologies (servlets, JSPs, tag libraries, and so on). With that out of the way, you can now move on to installing Tomcat. In later chapters, you learn the details of configuring it.
This chapter covers the following aspects of Tomcat installation:
Installing the Java Virtual Machine (JVM)
Installing Tomcat on both Windows and Linux
Understanding the Tomcat installation directory structure
Troubleshooting typical problems encountered while installing Tomcat
If you have installed earlier Tomcat versions (Tomcat 5.5 and before), you might be tempted to skip this chapter and move ahead. Indeed, Tomcat installation is reasonably straightforward. Check if you have JVM installed and in PATH, grab the Tomcat binary from the Apache Web site, unzip or run the installable, and you are good to go.
However, Tomcat 6 introduces some twistsa changed directory structure, and the requirement of Java SE 5 JVM. For that reason alone, we recommend that you read this chapter before going forward.
Tomcat is a powerful Web container that is made up of pluggable components that fit together in a nested manner.... more
Tomcat is a powerful Web container that is made up of pluggable components that fit together in a nested manner. The configuration of these components dictates how the server will run, including such settings as whether specialized filters are used, which ports and address a server may listen on, whether it uses security or not, what the virtual hosts are, and much more. Tomcat can be easy to use in its standard configuration because you are using a default configuration. However, when you begin to think about using Tomcat in a production environment, you need to make changes to the configuration to fit your requirements. This is where having good knowledge of Tomcat’s architecture comes in handy. Tomcat’s configuration files can appear cryptic and difficult to follow or understand, but they follow how Tomcat pieces together its components. Understanding Tomcat’s architecture can give you insight into the way Tomcat works and how its subcomponents make up a configuration.
This chapter explores Tomcat from an architectural perspective. The topics covered include:
Tomcat directory structure
Overview of the major Tomcat components
Relationships between the components to make a full service container
By the end of this chapter, you should have a comprehensive understanding of the Tomcat container architecture, its subcomponents, and their relationship to one another.
The focus of this chapter is on the basic configuration of Tomcat 6. The Tomcat 6 server is configured by setting parameter... more
The focus of this chapter is on the basic configuration of Tomcat 6. The Tomcat 6 server is configured by setting parameter values for the components of Tomcat 6 before starting the server. All architectural components (such as Service, Servers, Engine, Connectors, Realm, and Valve) can be configured. This chapter describes how to configure these components, the range of allowed parameter values, and how they affect Tomcat’s operation.
Tomcat 6 configuration information is always stored within one or more XML files. Numerous XML elements are in these files, and each element has attributes that correspond to a configurable aspect of a Tomcat 6 architectural component (see Chapter 4 for more information about Tomcat 6 architecture). This chapter examines each of these configurable attributes, and describes how they affect the behavior of the corresponding Tomcat 6 components.
This chapter provides a detailed, line-by-line explanation of the most important Tomcat 6 configuration files, including the server.xml file (the primary configuration file for Tomcat server instance), and context.xml file (the server configuration file for each Web application).
server.xml
context.xml
Special attention is paid to the default Tomcat 6 configuration in this chapter’s coverage. This default configuration exists in the form of a set of default configuration files that are included with the Tomcat 6 distribution. If you start Tomcat 6 without first editing any of the XML configuration files, this is the configuration that is used. Incidentally, it is also the bootstrap configuration that is used if you start up Tomcat 6, after enabling the administration tool, to make configuration changes. Therefore, it is important to understand what this special bootstrap configuration will do, and how you may be able to modify it for specific production environments.
This chapter also touches on some advanced configuration topics (such as Realm configuration and the configuration of fine-grained security policy control over Tomcat 6 server instances), but detailed descriptions of these concepts are provided in later chapters.
Tomcat 5.5 and earlier versions can also be configured using a Web-based GUI configurator called the admin Web application. Although this application has not yet been made available for Tomcat 6, this chapter includes an overview of its capabilities.
By the end of this chapter, you will be fluent with basic Tomcat 6 configuration, and will be able to configure Tomcat 6 by editing the XML configuration files.
You will also be completely familiar with the basic (default) configuration of the Tomcat 6 server, and will be able to modify this configuration for your own production needs.
Earlier chapters discussed Tomcat 6 administration basics, and Tomcat system architecture. This chapter explores a collection... more
Earlier chapters discussed Tomcat 6 administration basics, and Tomcat system architecture. This chapter explores a collection of administrative tasks that involve advanced features built into standard Tomcat 6. As a Tomcat 6 administrator, you are likely to encounter requests for many of these features from the development team.
More specifically, the following advanced administration tasks are explored:
Administering access logs
Working with single sign-on across Web applications
Request filtering
Installing a Persistent Session Manager
Setting up Tomcat JNDI emulation resources to provide developers access to external JDBC and JNDI resources
Setting up Tomcat for access to a JavaMail session
Configuring lifecycle listeners
Note that configuration of Realms, a very important advanced Tomcat 6 administration topic, is discussed in Chapter 14. A basic understanding of Tomcat 6’s security infrastructure is a prerequisite for appreciating the configuration options in Realms configuration.
This chapter serves as a “cookbook” for these specific tasks. For each task, the we provide reasons why a user or a developer may need the feature, followed by the configuration and administrative details. Finally, we present a practical sample configuration, which you can experiment with. Useful hints, tips, or problems that may apply are pointed out along the way.
Web applications consist of static content (such as HTML pages and images files) as well as dynamic content (such as servlets,... more
Web applications consist of static content (such as HTML pages and images files) as well as dynamic content (such as servlets, JSPs, and Java classes). Chapter 2 briefly discussed servlets and JSPs.
Although these Web applications usually are created by developers, they often require a system administrator to configure and deploy them, especially if the deployment is on a production machine. A systems administrator needs to know about a number of things in order to administer Web applications, such as the structure of a Web application and its configuration files.
This chapter describes the configuration-related issues for Web applications:
The structure and content of a Web application
The deployment descriptor for a Web application (that is, the web.xml configuration file)
web.xml
Chapter 8 discusses other administrative activities for Web applications (for example, deploying, undeploying, and listing Web applications).
This chapter discusses how to manage Web applications using the tools provided by Tomcat. Tomcat’s management tools... more
This chapter discusses how to manage Web applications using the tools provided by Tomcat. Tomcat’s management tools include the manager application, the admin application, and the new virtual-host manager. The manager application helps manage Web applications. It enables administrators to deploy Web applications, view deployed applications, and undeploy Web applications when necessary. While these tasks can also be performed manually by editing Tomcat’s configuration files, this method requires Tomcat to be restarted. The manager application automates these tasks and enables them to be performed on a running instance of Tomcat. This way, other Web applications that are already running in the same Tomcat container are left undisturbed.
A new management application added to Tomcat is the virtual-host manager. This Web application allows the remote management of the virtual hosts deployed on a Tomcat server: add, start, stop, and remove virtual hosts. The virtual-host manager is covered in more detail in Chapter 15.
virtual-host manager
This chapter covers the manager application. The chapter first looks at a sample Web application that is used as an example throughout the chapter. Then it discusses in detail the manager application, including the following areas:
manager
Enabling access to the manager application
The three ways of interacting with the manager application (the Web-based user interface, Ant scripts, and HTTP commands)
Security considerations while using the manager application
Every Java developer makes extensive use of class loaders, often without realizing it. Each time a class is instantiated... more
Every Java developer makes extensive use of class loaders, often without realizing it. Each time a class is instantiated as an object or referenced statically, that class must be loaded by the Java Virtual Machine (JVM) into memory. Thus, even statements as simple as String greeting = “hello” or int maxValue = Integer.MAX_VALUE make use of a class loader. They require the String class and the Integer class to be loaded, respectively.
String greeting = “hello”
int maxValue = Integer.MAX_VALUE
String
Integer
While class loaders are designed to operate fairly transparently from the developer’s point of view, there are subtleties to their use that are important to understand. Why a chapter on class loading in a Tomcat book? It turns out that class loaders and their behavior are a big part of Tomcat. Following the Servlet specification, Tomcat is required to allocate a unique class loader to each Web application. This chapter explains what this means and why it is important.
Following an explanation of class loaders in general and Tomcat’s class loaders in particular, we discuss common problems related to class loaders. By the end of this chapter, not only will you be familiar with class loaders in general, but you’ll also understand how they relate specifically to Tomcat.
The following topics are covered in this chapter:
An overview of class loaders
Security issues with class loaders
Tomcat and class loaders
Dynamic class reloading
Common class-loader issues
When used out of the box to run Web applications, Tomcat can serve HTML pages without any additional configuration.... more
When used out of the box to run Web applications, Tomcat can serve HTML pages without any additional configuration. This works because Tomcat has been preconfigured with an HTTP Connector that can handle requests from a user’s Web browser. Because of this Connector, Tomcat can function as a standalone Web server. It can serve static HTML pages, as well as handle servlets and JSP pages.
Tomcat Connectors provide the external interface (over HTTP or HTTPS) to Tomcat clients. There are two kinds of Connectorsthose that implement an HTTP stack of their own (called HTTP Connectors) and those that tie Tomcat to an external Web server such as Apache or IIS (called Web server Connectors). This chapter examines in detail the configuration of the various HTTP Connectors available in Tomcat 6. Chapters 11 and 12 discuss Web server Connectors.
The Java-based HTTP/1.1 Connector is the default Connector configured for Tomcat 6. It is an evolved version of the Java-based HTTP/1.0 and HTTP/1.1 Connectors appearing earlier in Tomcat 5.x.x versions of Tomcat. An earlier version of this mature Java-based connector is called the Coyote Connector, and has been available as an add-on from as far back as Tomcat 3.x.
In addition to the default configured Java-based HTTP Connector, Tomcat 6 provides a variety of alternative HTTP Connectors. A Java HTTP Connector written to take advantage of the high performance IO features of the Java 5 NIO library is available. In addition, a native version of the HTTP Connector, written in C/C++ and coded to APR (Apache Portable Runtime) is also available. While both of these alternative Connectors are relatively new compared to their default Java Connector cousin, they hold much promise for the near future.
Even though very little additional configuration is required to get the HTTP Connector working, you may want to fine-tune some of its features. This chapter describes what to do when your Connector configuration needs to be modified, such as for specific deployments (for example, running Tomcat behind a proxy), SSL setup, or performance tuning.
The following areas are covered in this chapter:
Using Tomcat 6 default Java HTTP/1.1 Connector
Using Tomcat 6 Java NIO (Advanced IO) HTTP/1.1 Connector
Using Tomcat 6 native APR (native code) HTTP/1.1 Connector
Blocking and non-blocking operations
Supporting Comet
Running Tomcat behind a proxy server
Setting up SSL
Performance tuning
A typical scenario in production environments is to use Tomcat along with a Web server. In this scenario,... more
A typical scenario in production environments is to use Tomcat along with a Web server. In this scenario, the Web server is used as a frontend to Tomcat. The Web server serves all static content and Tomcat serves all dynamic content. Tomcat does have its own built-in HTTP server, but some administrators managing large Web server farms may insist on using a well-known and robust Web server to accept requests from the Internet. A number of Web servers can be used for this purpose (including Apache, IIS, and Netscape). This chapter describes the process of connecting the Apache Web server to Tomcat.
Tomcat can be integrated with Apache using the JK Connector. This chapter explains how to install and configure this Connector. The JK Connector uses the Apache JServ Protocol (AJP) for communication between Tomcat and the Apache Web server.
The AJP (Apache JServ Protocol) Connector and the JK module (mod_jk module)
mod_jk
The AJP Connector and the mod_proxy module
mod_proxy
The installation and configuration of Tomcat 6 with Apache 1.3.x
The installation and configuration of Tomcat 6 with Apache 2.0.x
The configuration of Tomcat 6 with Apache 2.2.x and mod_proxy support
Configuration of SSL for Apache 2.2.x servers
Load balancing multiple Tomcat instances with Apache
Each of the 1.3.x, 2.0.x, and 2.2.x series of the Apache server has slightly different architecture and feature sets. A later version does not necessarily displace another, and each version has its own strong following of server administrators. This chapter covers configurations of Tomcat 6 with each series of Apache server. The techniques demonstrated are tested against Tomcat 6; Apache 1.3.37, 2.0.59, and 2.2.3; and mod-jk2-2.0.43 with Sun’s JDK-1.5_11. It is assumed your required version of the Apache Web server is installed, configured, and running on the system. Apache binaries are available for download at apache.org/dist/httpd/.
mod-jk2-2.0.43
apache.org/dist/httpd/
The complete Apache documentation is available at http://httpd.apache.org/docs/.
http://httpd.apache.org/docs/
The previous chapter discussed how Apache could be used as a front end to Tomcat. This chapter details the use of Internet... more
The previous chapter discussed how Apache could be used as a front end to Tomcat. This chapter details the use of Internet Information Services (IIS) with Tomcat. IIS is a popular Web server for Web sites hosted on Microsoft platforms and is used for deploying server-side solutions developed in ASP, C#, and other Microsoft technologies. The primary reason for running IIS along with Tomcat is to allow service providers to support heterogeneous server-side solutions (for example, both ASPs and JSPs) on the same platform.
The Tomcat project provides an Internet Services Application Programming Interface (ISAPI) redirector plug-in for connecting IIS and Tomcat. This chapter covers installation and configuration of the ISAPI plug-in to connect Tomcat with IIS, including the following topics:
Role of the ISAPI plug-in
Configuring Tomcat and IIS to work together
Suggested architectures offering greater scalability
Troubleshooting tips
The configuration described in this chapter has been tested with IIS 5, which is the version supported for Windows XP Professional and Windows 2000 Server. For deployments on IIS 6 (i.e., on Windows Server 2003) you need to switch IIS to the IIS 5 isolation mode, as described later in the chapter.
Most Web applications process data, and that data is often stored in a database. The most popular database management... more
Most Web applications process data, and that data is often stored in a database. The most popular database management systems are based on relational concepts, and are appropriately called relational database management systems (or RDBMSs).
All popular databases (including Oracle, MySQL, SQL Server, Sybase, Interbase, PostgreSQL, and DB2) are relational databases. Tomcat administrators must be well versed in RDBMSs. In addition, an understanding of the nature of interactions between an RDBMS and Tomcat is required to better anticipate the requirements that may arise.
This chapter addresses the following topics:
Java Database Connectivity (JDBC), which is Java’s database connectivity API
JDBC version evolution
JDBC driver types and advantages
Importance of connection pooling
Interactions between RDBMS and Tomcat
JNDI-based JDBC configurations
Standard configuration for a JDBC data source
Alternative JDBC configurations that may be required
Configuring alternative JDBC access
This chapter also covers a variety of situations that may arise when configuring Tomcat to work with relational databases. The examples offered in this chapter feature hands-on configuration. Special emphasis is placed on the recommended or preferred way of interacting with databases.
After reading this chapter, you will be comfortable with the integration of RDBMSs with Tomcat, and will be able to handle the most common requests for configuring RDBMSs to work with the Tomcat server.
Perhaps no topic in the computing industry receives more emphasis than security, and for good reason.... more
Perhaps no topic in the computing industry receives more emphasis than security, and for good reason. As network computing enters the twenty-first century, it is clearer than ever that the Internet is not a safe place. Attacks can be simple pranks (such as defacing a Web site), or take much more serious forms, such as industrial espionage, sabotage, or the theft of consumer information. System administrators must take many steps to secure network-exposed systems and services (such as Tomcat) against such aggressions.
This chapter covers topics relating directly to the security of your Tomcat server and applications running on it, including:
Verifying initial download integrity
Securing Tomcat against common attacks
Running Tomcat with an unprivileged user account
Locking down the file system
Limiting access to Web applications with authentication Realms
Turning off DefaultServlet directory listing capability
Guarding against default web.xml configuration vulnerability
Encrypting communications between Tomcat and application clients with SSL
The discussion of security issues surrounding the Tomcat server and applications is not entirely platform-agnostic. However, this chapter does not attempt to provide platform-specific instructions for all operating systems. Where appropriate, specific instructions are provided for Windows 2003/XP and Linux operating systems. Despite some pockets of platform-specificity, the principles shared in this chapter are applicable to any secure operating system. This chapter does not cover other production network security issues (such as the configuration of security firewalls, DMZ setup, and so on) not directly related to Tomcat configuration.
Many small businesses do not need, or cannot afford, the cost of running a Web site hosted on a dedicated server or a... more
Many small businesses do not need, or cannot afford, the cost of running a Web site hosted on a dedicated server or a cluster of servers, and hiring IT engineers to maintain them. A common solution for these businesses is to use a hosting service provided by an Internet Hosting Service Provider. Typically, these hosting services are shared hosting situations in which multiple Web sites can be running on a single computer. Running of more than one Web site on one computer is called virtual hosting.
These hosting services allow for the sharing of resources such as the Web server, database server, mail server, firewall, and so on. Thus, all the services that are typically used in this scenario must have built-in support for shared hosting.
The following shared hosting topics are covered in this chapter:
An introduction to virtual hosting terminology
Virtual hosting using the Apache HTTP server
Virtual hosting using Tomcat in both a standalone configuration, as well as with the Apache HTTP server.
Options for tuning Tomcat resource usage in a shared hosting situation
Apache 2.2, Tomcat 6, and mod_jk are used for all of the examples in this chapter.
As a Tomcat administrator, you are likely to be completely comfortable when working with XML configuration files,... more
As a Tomcat administrator, you are likely to be completely comfortable when working with XML configuration files, examining detailed logs, and interacting with management application such as the Tomcat Manager application. Logs provide debug traces when configuration mistakes are made, or when a system exception occurs. The Manager application enables remote start, stop, installation, and removal of applications. It also provides visibility into some information on the running applications. By and large, however, while a Tomcat server is up and running, there is very little you can do to ascertain the current state-of-health of Web applications and the Tomcat server. This is not really limited to the Tomcat server; there really is a lack of monitoring and management facilities for servers created on the Java platformthat is, until Java SE 5!
Starting in Java SE 5, and improved in Java SE 6, are the features known as Monitoring and Management (M and M). The M and M platform and tools support enable applications to be monitored and managed in real timewhile they are runningeither locally on the same machine or remotely over a network. The enabling technology is actually called Java Management Extension (JMX). Support for JMX is built extensively into the Tomcat server since version 4, and is relatively mature in Tomcat 6. This chapter discusses the following topics:
JMX and manageability requirements
Introduction to JMX
JMX internals
Configuring Tomcat 6 for JMX operations
Using Manager Application JMX Proxy to monitor and manage Tomcat instances
JDK tools for monitoring and management
Utilizing the JMX support of Tomcat 6
A hands-on example shows you how JMX can be used to obtain live runtime information directly from the components that make up the Tomcat 6 server.
Administrators should be familiar with JMX and its implications because most administrative and management tools for Tomcat are based on JMX. Using standard tools included with Java SE 6 (JDK 1.6), an administrator can help you monitor the health, and manage the operation, of your Tomcat 6 servers.
The Tomcat server has grown up, from a reference implementation of a Servlet container for demonstrating and testing new... more
The Tomcat server has grown up, from a reference implementation of a Servlet container for demonstrating and testing new APIs to a robust and high-performance Web-tier server. Increasingly, Tomcat is being used in production scenarios to handle real-world Web applications. It is a prime example of a prototype becoming the product. In a sense, the designers and architects realized that their mission changed direction, and they redesigned the Tomcat product for high-stress production deployments.
Tomcat 6 is further along the evolutionary path of improved performance. Real-world deployments place many tough demands on the Tomcat server. Many of these requirements were not important to the Tomcat development team when it was a mere reference implementation. Two such areas are support for horizontal scalability (the ability to handle increasing user requests by utilizing a group of physical machines) and high availability (the ability to survive hardware or software failures and maintain a high percentage of application uptime). In other words, what happens when there are so many users that Tomcat servers start to crash, and how can you ensure that no user loses data? These are real-world problems, and Tomcat 6 attempts to solve them by providing built-in support for clustering. Clustering, in this context, refers to running multiple instances of the Tomcat server so that it appears to users as a single server.
This chapter covers the many facets of Tomcat 6 clustering, including the following:
Basic principles of clustering
How Tomcat implements clustering
Internal software components that implement Tomcat clustering
Technologies that underlie Tomcat clustering
Various alternative configurations
Last but not least, the chapter gives you hands-on experience with configuring and experimenting with this exciting feature of Tomcat. You will be working with three different clustered configurations along the way. As an epilogue, the chapter offers some practical suggestions about clustering that may affect your decision to deploy the technology.
Ever since the initial availability of the Tomcat server, some developers have wanted or needed to create applications... more
Ever since the initial availability of the Tomcat server, some developers have wanted or needed to create applications that have full control over the server’s lifecycle and internal operation. When the entire Tomcat server is contained within a custom application, it is said to be operating in embedded mode. While provisions were made for embedding Tomcat into applications in past releases (as far back as Tomcat 3.x), these older provisions were rather ad hoc and problem-prone because the earliest versions of Tomcat did not account for the embedded mode of operation. Tomcat 5 changed this landscape completely. Embedded operation is an explicitly supported mode, and Tomcat 6 and future Tomcat designs will evolve to satisfy the emerging requirements from embedded users.
This chapter explores the embedded mode of Tomcat 6 in the following areas:
Why embedding Tomcat may be important for many projects
Programmatically embedding Tomcat
Developing a real embedded Tomcat application
Hands-on examples are provided so that you can experiment with configuring embedded Tomcat instances. This chapter focuses more on the under-the-hood aspects of embedded Tomcat implementations.
By the end of this chapter, you should have a comprehensive understanding of why you might use embedded mode and how to operate Tomcat in embedded mode. You will be able to facilitate the creation of applications and systems that operate embedded Tomcat instances.
Tomcat versions before 6.x included Ant scripts that provided embedded control and access through JMX. Although Tomcat still includes JMX extensions, it has dropped support of the embedded Ant scripts, and therefore this chapter does not cover them. This chapter covers the programmatic embedded implementation.
Logging is critical for Web applications, as often there is no other way to debug issues on production machines.... more
Logging is critical for Web applications, as often there is no other way to debug issues on production machines. Also, adding log statements is the only viable option for analyzing the execution of a long-running Web application.
This chapter discusses logging, both internally by Tomcat as well as by Web applications themselves. This chapter covers the following:
A short, tutorial-style introduction to both log4j and Java Logging.
Logging concepts and best practices, such as rolling logs, maintaining information in log messages to be able to identify the source of the error, and much more.
Solutions ("recipes") for common tasks that developers and system administrators need to do while developing effective logging solutions for their applications. Some of these include:
Logging to different destinations, such as a file, system console, or even the system logger (syslog, NT logger)
Being able to notify administrators via e-mail of specific log messages, such as serious errors
The chapter also introduces administrators to tools that they can use to manage the large amount of log data generated.
So far in this book, we have examined how to install, configure, and secure a distributed Tomcat environment.... more
So far in this book, we have examined how to install, configure, and secure a distributed Tomcat environment. After expending the effort needed to install, configure, and tweak an installation, it is indeed a sad moment for a system administrator to see it all subverted because the application server buckles under a production load. Therefore, it is vital that administrators verify the performance characteristics of their Web applications before they are deployed for production use.
This chapter covers the concepts and processes of performance testing. By the end of the chapter, you will:
Appreciate the importance of performance testing
Understand how to develop a performance test plan
Know how to use the Jakarta JMeter framework for performance testing and how to interpret the results
The previous chapter ended with a section called “What to Do After Performance Testing.”... more
The previous chapter ended with a section called “What to Do After Performance Testing.” It advised you to first analyze the root cause of poor performance before attempting a fix. This chapter covers some of those steps in more detail.
First, we discuss general best practices for approaching a performance tuning project, such as setting up a test bed, establishing a performance baseline, making incremental changes for tuning performance, and measuring performance changes, if any, against this baseline.
Next, we suggest where to look for performance bottlenecks, and how to identify the root cause when faced with specific Tomcat issues.
Finally, we list design and development choices, and configuration options that affect performance in Web applications in general, and Tomcat-hosted applications in particular. Some of these tips might be common knowledge among Web developers, and others are mentioned elsewhere in the book. This section collects these tips in one place.
Performance tuning is a complex area, and the factors that affect performance are sometimes outside the application itself. These factors may include the network configuration and hardware platform characteristics, the operating system settings, Java virtual machine parameters, database tuning parameters, and finally the architecture of the Web application itself. Naturally, everything that affects performance cannot be covered here. The objective of this chapter is twofold: first to give you a feel for how to approach performance tuning in general; and second, to explain how to go about tuning the Tomcat configuration and your Web application for improved performance.
Java has a rich set of Integrated Development Environments (IDEs), both open source as well as commercial.... more
Java has a rich set of Integrated Development Environments (IDEs), both open source as well as commercial. These IDEs enable application developers to develop, compile, debug, test, and deploy Web applicationsall from within the IDE itself.
This appendix outlines the support for Tomcat in the following IDEs:
Eclipse
NetBeans
At the end of this appendix, you will be able to use either of these IDEs to debug Web applications deployed to a Tomcat serverboth a local server as well as a remote one.
This appendix covers the two widely used open source Java IDEs, but does not cover the commercial ones such as Intellij IDEA (www.intellij.com) and JBuilder (www.borland.com/jbuilder). However, some of the steps are similar across IDEs, such as those for remote debugging a Web application in Tomcat. The appendix also does not cover installation of either Eclipse or NetBeans, or how to set up a project in these IDEs.
www.intellij.com
www.borland.com/jbuilder
Ant is the de facto standard for creating cross-platform build scripts for Java applications. An important feature that... more
Ant is the de facto standard for creating cross-platform build scripts for Java applications. An important feature that led to its popularity is the capability it offers developers to extend it via custom tasks. In Chapter 8, you learned how Tomcat’s custom Ant tasks can be used to deploy and undeploy Web applications without the need to restart Tomcat. This means that not only can you build your application using an Ant build script, but you can also go a step further by installing, removing, reloading, or monitoring the Web application from the same build script. You can do a lot more with Ant, as this appendix illustrates.
This appendix provides a comprehensive overview of Ant features and capabilities. It covers the following:
A short, tutorial-style introduction to Ant.
Solutions ("recipes") for common tasks that system administrators need to do while developing build and deploy systems. Some of these tasks include:
A basic build script for a Web application
Making this build script reusable for different environments using property files and command-line parameters
Sending notifications of successful (or failed) builds to developers via e-mail
Ant and source code control systems
Further references for setting up a continuous integration environment
A reference for common Ant tasks.
Purchase Before purchasing this product, please be sure you have met all software and system requirements, and that you understand any limits placed upon its use.
Return Policy Wrox Chapters on Demand are non-returnable and non-refundable.
Reader Software Wrox Chapters on Demand are offered as PDFs, and they must be viewed using the Adobe Reader. If you do not have the Reader installed, it can be downloaded for free at Adobe.com.
Test Download As Wrox Chapters on Demand purchases are non-returnable, it is advisable that you test your system and software configurations with a free sample download before you place an order.
Usage Rights for a Wrox Chapter on Demand File Any Wrox Chapter on Demand product you purchase from this site will come with certain restrictions that allow Wiley to protect the copyrights of its products. After you purchase and download this title, you:
If you have any questions about these restrictions, you may contact Customer Care at (877) 762-2974 (8 a.m. - 5 p.m. EST, Monday - Friday). If you have any issues related to Technical Support, please contact us at 800-762-2974 (United States only) or 317-572-3994 (International) 8 a.m. - 8 p.m. EST, Monday - Friday).
Related Books
Java Resources