Slashdot Mirror


How Tomcat Works

Petri Aerikkala writes "Don't judge a book by its cover, but by what it covers. How Tomcat Works has a very ordinary cover, but I cannot overemphasize how useful its contents are. This book does what the title says, plus much more. It is useful for not only those using Tomcat or those working with servlets/JSP/J2EE, but also for all Java developers in general." Read on for the rest of Aerikkala's review. How Tomcat Works author Budi Kurniawan and Paul Deck pages 458 publisher BrainySoftware rating 8 reviewer Petri ISBN 097521280X summary Explains how Tomcat works and how to build a servlet container of your own

First of all, this is the only book I know of that explains how the complete system works. You can find good documentation on how to use this most popular servlet container on the Tomcat project's Web site, but little is said about how it works. If you want to join this open source project, good luck. You should consider yourself lucky (or very brilliant) if you can understand how the system works in less than 3 months by browsing through its millions of lines of code.

However, why I find this book appealing is because of the approach the authors take in analyzing it: build Tomcat from scratch, line of code by line of code, module by module. Miraculously, in doing so they never fail to make sure their readers can follow the technical discussions. In their hands, Tomcat looks easy that even beginners of Java can understand. There are many complex technologies used in Tomcat, and they are all explained well.

The book starts off by building a dummy Web server that can do no more than sending a static HTML page. The web server is simple and consists of only three classes. The backbone of this application is the java.net.Socket class, and the authors take their time explaining this class at the beginning of the chapter. Basically, this is how the application in this chapter works: for each HTTP request, open a socket connection to the client, read the content of the static file, and send the file to the browser. As simple as that.

Chapter 2 builds on the application in Chapter 1. In this chapter, the web server gets some intelligence. It is now able to invoke a basic servlet by calling the servlet's service method. However, more complex servlets are beyond this simple servlet container, mainly because the container passes a null ServletRequest and a null ServletResponse objects to the service method. Before the authors start coding, they explain the javax.servlet package in general so that those new to servlet programming can understand this chapter.

Chapter 3 explains how to create ServletRequest and ServletResponse objects so that the servlet container in Chapter 2 can do more. The excitement comes in Chapter 4 when the authors explain how to pool ServletRequest and ServletResponse objects to beef up performance. This topic is not only relevant to Tomcat, but also Java programming in general. Object instantiation is expensive, and one way to avoid it is by reusing objects. However, you must be careful when your application will be used by many clients, as you must then think about thread safety. Chapter 4 elegantly explains how Tomcat developers solve this problem, as well as teach you a general solution for object pooling. Interestingly, a servlet is always represented by a single instance, and the same instance services all incoming requests.

The authors are also patient in explaining everything step by step, until the last chapters where they tackle more difficult problems such as Digester, JMX, class loaders and session management.

Not only will you be good at configuring Tomcat after you are finished reading this, you will also be able to tell straight away what's going on whenever your Tomcat installation throws up some error message. In addition, if you are really serious about Tomcat, you can start thinking of writing your own modules or extending the existing ones. For example, as the authors have demonstrated, you can extend Tomcat's application loader to automatically reload a Struts application when the struts-config.xml is modified, making the application development process quicker.

This book is also great in answering many questions that seasoned servlet/JSP programmers might have long been pondering. For example, this book discusses the difference between an OutputStream and a PrintWriter, and why you can only use one of them rather than both. It also tells you why you cannot write to the request parameters or headers.

Now, as much as I liked it, this book is not perfect. The first noticeable flaw is that there are quite a number of disturbing spelling mistakes. Also, the index could have been better, not to mention a cover that is plain and uninspiring. However, I have to admit I am very happy with this book and will recommend it to any Java programmer.

You can purchase How Tomcat Works from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

2 of 171 comments (clear)

  1. Re:Sounds like a nice book... by Anonymous Coward · · Score: -1, Redundant

    You know, my skool switch ed recently to Gentoo and that tomcat ebuilds really rock. Not only were they rock solid, but they were compiled for my hardware so they ran faster.

    Sorry if I am gentoo-horing, but I really think that that might be yur problem. Just make sure that you don't listen to some of the idiots around here who just "dont get it" cause they dont get it.

    G3ntooDud3

  2. Re:How does it compare to OReillys book? by Anonymous Coward · · Score: -1, Redundant

    A Servlet is a sort of mini webserver. You get all the necessary webserver things (security, session management, timeout, cookies, etc) from the Container you plop your Servlet into (usually Tomcat, though there are plenty others available both commercial and open source). That way you can concentrate on writing the application code you want in the Servlet, with all the resources available from the Java libraries.

    Servlets were popular, but the basic thing a servlet expected was Java code, and people soon realised that it was a bit cumbersome to do the most basic thing, namely write back to the client:

    outStream.print("<HTML>")
    outStream.pr int("<HEAD>")
    outStream.print("</HEAD>")
    outStre am.print("<BODY>")
    outStream.print("Hello" + user.getName() + ".");

    So they turned Servlets inside out and called it JSP. Now, the JSP expects HTML code, and you do a special tag instead to write Java:

    <HTML>
    <HEAD />
    <BODY>
    Hello
    <% out.println(Utils.getUserNameFromCookie(request)); %>.
    </BODY>

    Much easier. At load time, a JSP is turned into a Servlet though, but this is done transparently for you.