Slashdot Mirror
How Tomcat Works
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.
I have been paid to build MS apps for years now, but I have "watched" Java from a distance and have to say that if I started a business of my own, all applications would be written in Java/JSP. I was one of the first to attempt to build Tomcat on a Windows system and after many disasters came to love it. The inner workings of Tomcat often baffled me and now I am gonna have a book! Sadly nothing I learn will translate to my current job, but it'll be damn fun.
--I smoked my sig.
I've deployed a few sites on Tomcat for my current employer. We have two setups, a Windows 2000 server and a Suse 8 server both shared. The Linux server seems to be able to stand up to the pressure of the busier sites a bit better but that's probably because our admin guy as it set up better.
Some of the sites on the windows box go down once a day or more, but again that's probably a configuration thing. I've never had any problems developing on either.
IMHO Tomcat has come a long way in the last few years. Version 5 is a huge improvement over version 3.2 (I never got around to deploying a live site on 4.x, those apache guys are way too fast for me!)
From the point of view of someone who's been developing with Tomcat over that last few years the book sounds fairly interesting but not meaty enough. It sounds like a great starting point for someone interested in understanding Tomcat but not much more. I'd like to see a follow up book that goes into more detail then I'd probably buy the two, as it is it would probably whet my appetite and leave me unsatisfied.
"hehe, website" - Homer Simpson
Add to that security.
I keep getting flamed by the moderators but do a search on the CIA's website for insecure langauges and software.
Php is the least secure langauge in existance and has more holes than even ASP.
I do not mean to sound trollish but its the truth and the next big wave of worms will probably be targetting at websites running php.
http://saveie6.com/
My servers all run Tomcat. A good chunk of them are still running Tomcat 3.1 for legacy reasons.
The sites are high-traffic (many hundreds of user sessions per day). "Hundreds" probably doesn't sound like much, but the apps are pretty intense...not just simple SQL query/display stuff. High-end graphics manipulation, workflow management, and more, with sessions lasting 10-20 minutes each.
The base OS on every server is Red Hat. Rarely do we experience problems, and in 99% of the cases, the problems are user-related (as in "problem exists between chair and keyboard"), not code related. Very very stable all around, both the Tomcat 3.1 installations and the Tomcat 4.1.x installations. I wouldn't use any other servlet container. Aside from the "plus" of the Apache license, I see no reason to "fix" something that isn't broken by trying other servlet containers, no matter what their claims.
Because of our positive experiences with Tomcat, we started rewriting a major internal application about 8 months ago. It was originally written in ASP with COM+ objects. We initially thought we would need to get into some sort of J2EE scenario in order to "mimic" the COM/COM+ architecture, but after some proofing was done, we quickly realized that we were fine with servlets and JSP using a tweaked MVC architecture. No problems with load, and we can scale as we need to.
As a comparison, and no, this isn't a troll, the ASP stuff we have crashes frequently. None of the applications running in production with Tomcat crash.
I highly recommend Tomcat, and the people on the project, the dev and user lists, etc. are generally good people and very helpful.
Maybe I'm just out of it, but the thing that kills me here - is I have yet to see how this is going to provide some functionality in the real world that couldn't be done easier and simpler 1000 other ways.
Oh, and also - all this reminds of when I herd ESR say in a talk that the markets cry for java was really a cry for FOSS. While I've never been a great fan of ESR - I think maybe he was right. The whole idea of java was to move the development center of gravity away from the proprietary desktop. Heck firefox and PHP have alone have done 10 times what java has to accomplish that. And php isn't even client side for chrissake.
ANd, also I think it was a mistake to force the java solution to be a high level language. What they should have done is made some standadrized client side byte codes that did simple functionality like IO, and things like AND, OR, NOT, +, -, GOTO, etc and put it in a simple sceure "box", and then leave to the higher lever implementations to "compile" the byte codes and add layers on it. - Then the market could have sorted out the best high level solution. As it is, all the 'simplicity' and 'uniformity' we were supposed to get from java has simply been thrown out the window because of all the layers of high level crap you half to go thru to get things done.
IMHO, the whole direction had completely thrown KISS out the window - either me or them are going insane.