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.

19 of 171 comments (clear)

  1. Re:Could the editors... by Anonymous Coward · · Score: 1, Informative

    Tomcat is a software project to implement the Java Servlet specification. It's developed by the Apache group.

    It lets you deploy your Java Servlets and JSP pages, among other things.

  2. Re:I feel stupid but... by brittm · · Score: 5, Informative

    Tomcat is a Java servlet container--that is--basically a web server that serves up Java servlets, JavaServer Pages, etc.

    It can run standalone and also serve static files such as HTML pages/graphics, etc., or it can be configured to stand behind a web server such as Apache and only handle the servlet and JSP requests that are passed to it.

    Tomcat is itself written in Java and is, of course ;) open source. See more at http://jakarta.apache.org/tomcat/index.html.

  3. How does it compare to OReillys book? by Anonymous Coward · · Score: 5, Informative

    Anyone know how this books compares to the O'Reilly book, " Tomcat: The Definitive Guide"? Also, it might be helpfull for people to know what a Servlet and JSP is before spouting out terms.

    About the only thing common between an Applet and a Servlet is that both are writen in Java. Anyone out in /.land using Tomcat for their production site? Also, any care to give any recomendations for an eclipse plug-in?

    1. Re:How does it compare to OReillys book? by michaelggreer · · Score: 2, Informative

      I have used Tomcat in production many times, and for the most part it is excellent. The only trouble has been with commons.logging (grr..), the default connection pool (use c3p0 instead), and context reloading with Hibernate (only a dev problem). Resin gives it quite a run for performance, but its not free. As for plugins, Sysdeo has a great one that lets you run it in the debugger, with hot-code replace and everything

    2. Re:How does it compare to OReillys book? by michaelggreer · · Score: 2, Informative

      Well, since you asked: SessionFactory is not well serialized so when you reload the context, Hibernate creates a new one. This is because (I believe) you can't put it in JNDI in Tomcat. Thus, each time you reload you get an extra (and big) SessionFactory, and eventually run out of memory. However, if you use the Eclipse plugin (hot-code replace instead of context reloading for class changes), you will not need this so often. And certainly you shouldn't be reloading contexts in production: restart Tomcat instead.

  4. Would have been nice by suso · · Score: 4, Informative

    To have known how Tomcat works this past weekend when I was setting it up for a client. WHat a nightmare. Reminds me TOO MUCH of setting up Chilisoft ASP for Apache. Sure its a good idea, but I think its implemented poorly and from an administrators point of view, I found it hard to know where to start. The documentation for setting up Tomcat needs to assume that the administrator doesn't have any knowledge (or little) of Java.

  5. Re:I feel stupid but... by Anonymous Coward · · Score: 1, Informative

    A female cat is a queen, not a pussy.

  6. Re:A new copy is not available from Barnes & N by meshko · · Score: 3, Informative

    Oh yeah?
    And maybe someone just wants to make money on their amazon referral?
    It is available from BN for $10 less.

    --
    I passed the Turing test.
  7. Re:Could the editors... by brittm · · Score: 3, Informative

    Actually, Tomcat isn't an Apache plugin. Tomcat is a stand-alone server that can also be configured to support Apache for serving up Java web applications (which Apache cannot do on its own).

  8. Re:And those are? by rutledjw · · Score: 2, Informative
    Not wanting to be rude - but do your own research.

    If you're a student, particularly in a technical field, you should be able to google something and learn what it is. As you progress in your technical career, you'll spend a lot of time looking up technology and solutions. It's the nature of a fluid field.

    My EE profs had no patience with students who wouldn't do their own research and I've been the beneficiary of that attitude.

    Learning a topic is something that should be obvious. If you are to be competitive and desirable in a tough industry - you should be used to it

    --

    Computer Science is Applied Philosophy
  9. Re:Is it just me by temojen · · Score: 5, Informative
    what does Tomcat offer me that PHP does not, other than needless bloat and heavy system requirements?

    1. Persistant in-process objects,
    2. The ability to respond to a HEAD or PUT request, not just POST and GET,
    3. A strongly typed language (which is alledgedly more secure),
    4. and background threads not dependant on any particular request.
  10. Object instantiation is cheap! by Bubblehead · · Score: 5, Informative
    Contrary to popular believe, object instantiation is quite cheap these days (see Hotspot Garbage Collection FAQ for great information on this topic). Over the years, garbage collection algorithms have changed quite a bit. As most objects are short-lived in a well-designed OO system, GCs are tuned to exploit that. In fact, if the object is disposed in less then 4-6 GC cycles, the cost is almost nothing, and it gets more expensive, the longer the object is kept around. This is the case because young generation objects are never copied within the heap, while old generation object may be copied multiple times.

    From this follows that object pools are counterproductive for performance (unless, of course, if resources are associated with them, like Database connections, open sockets, etc.).

    I heard that quite a few app servers (including JBoss) started to refactor to get rid of object pools, but I don't have a link to back this up.

    --
    Under capitalism man exploits man. Under communism it's the other way around.
    1. Re:Object instantiation is cheap! by FerretFrottage · · Score: 2, Informative

      Very true...object pools in multi threaded systems with proper synchronization can often be counterproductive (in terms of time saved) to just creating a new Object. If you are truly pooling objects to save some state information, then a prototype pattern may be a better way to go. Obviously it all depends on the design and what the developer intends to do with the objects, but in general, keeping the objects in the "eden"/young memory space is most desirable (in terms of gc) Not sure how this plays with Java 5 yet as I have not profiled on that version.

      --
      "Look Lois, the two symbols of the Republican Party: an elephant, and a fat white guy who is threatened by change."
    2. Re:Object instantiation is cheap! by blamanj · · Score: 2, Informative

      Indeed. There are relatively few things that are expensive to instantiate, such as threads and databases connections. This isn't new, either, generational collection has been around since 1.3.

      Another case of premature optimization hurting (in added complexity and potential bugs) more than it helps?

  11. Re:Is it just me by Anonymous Coward · · Score: 1, Informative

    Well, there is also porting to other containers (i.e. WebSphere). You also can take advantage of all the industrial strenght (and tested) libraries available. Not to mention the volume of books on the subject.

  12. Sample Chapters by kyoko21 · · Score: 3, Informative

    You can read some sample chapters here. Just use your favorite archiving application and acrobat reader(neither included).

  13. Strongly Disagree with Review: Not a Good Book! by SarahAnnAlien · · Score: 5, Informative

    My boss came into my office a few minutes ago, saw this book on my desk, and asked if I had seen the review on Slashdot. I laughed a bit and said I had. I read this book many months ago, and told my boss about it.

    "How Tomcat Works" is a potentially good idea, done badly.

    The writing is awful. Not just inelegant, but frequently so bad that it gets in the way of the ideas being presented. Spelling, typos, grammar problems, convoluted sentences, miswordings that invert the meaning of a sentence entirely: this book has all that, and more. A fourth grade teacher with a red pen would have made this a much better book.

    A book on "Tomcat Internals" is a wonderful idea; Tomcat's a somewhat complicated beast. But the approach that this book takes... it just didn't work for me. It's possible that I simply couldn't get past the bad writing. Or it may simply be that it doesn't meet my needs. I'm familiar enough with Tomcat that I don't need it explained in tiny little baby steps. What I do need, when I'm up to my ankles in Tomcat internals and trying to solve a particular problem and get on with my life, is a clean, well organized book that will quickly get me oriented, refresh my memory on the relevant bits of Tomcat's architecture, and point me to the solution to my problem. This book fails to do that.

    The production values in this book leave a lot to be desired. There aren't enough diagrams, and, at least in my edition, the few that do appear are printed at very low resolution. The index is a joke. (Hint for the authors: a quick indexing script doesn't always make a useful index, okay? Second hint: hyphens denoting sequential pages are cool.)

    I've learned a lot about Tomcat since reading this book... mostly by wading through the source code. After a quick initial read-through, "How Tomcat Works" has stayed on my bookshelf, untouched, for at least five or six months. This book will join "Apache Server Commentary" in the pile of books that seemed like a really good idea, but in the end, were much less helpful than I had hoped.

    If you just need a book on installing or using Tomcat, or writing Java servlets in general, there are many better books. If you need a book on Tomcat internals, you probably need a better book than this one.

  14. Re:I don't want to start a holy war by MaxwellStreet · · Score: 2, Informative

    Remember that JSP's are simple shorthand for objects that eventually get compiled into full-fledged servlets upon their use (or earlier, if you precompile them when deploying your app). The difference between JSP's & servlets is a development-time issue only.

    And there is no reason at all to mix business logic & content - in fact, application frameworks like Struts make it *hard* to do so.

    The rest - slowness, memory use, etc. - could apply to any commonly used platform. I've seen studies that put certain types of java code as faster than the "managed" code of the .NET framework. Unless you're coding your web pages in C, this "slowness" or "memory use" will be an issue, as anything else (.NET, perl, php, etc.) is all interpreted.

    Or perhaps IHBT. HAND.

  15. Tomcat is NOT a J2EE server by danwiz · · Score: 5, Informative

    It is useful for not only those using Tomcat or those working with servlets/JSP/J2EE ...

    As a J2EE programmer, I find the reviewer's statement to be a bit misleading.

    Tomcat is not a J2EE server. The J2EE specification deals with Web Components (Servlets, JSPs) and EJBs (various EJB types and related services). Tomcat only satisfies part of the the full J2EE specification by serving Servlets and JSPs. Therefore, Tomcat is only a Web Container.

    JBoss is an example of a J2EE compliant app server.