Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×

How Tomcat Works 171

Posted by timothy from the purring-and-whining dept.
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.
This discussion has been archived. No new comments can be posted.

How Tomcat Works More

How Tomcat Works

Comments Filter:

  • Judge (Score:5, Funny)

    by MikeMacK ( 788889 ) on Monday November 15, 2004 @06:08PM (#10824315)
    Also, the index could have been better, not to mention a cover that is plain and uninspiring.

    But I thought we weren't supposed to judge the book by it's cover?

    • Re:Judge (Score:1, Insightful)

      by qcubed ( 655212 )
      its, not it's.
    • That's cute. Of course, that's not what he's doing at all: he's clearly judging the design of the cover on its artistic merits, not judging the contents of the book by said cover. This is entirely self-consistent with his earlier admonishment, so the humor of your question falls a little flat.

      Really, if you're going to be (even humorously) pedantic, you might take more care to be correct.
      • I agree it's not one of my better jokes, but then again coming up with funny stuff when talking about technical book reviews is an art unto itself.

    • Re:Judge (Score:3, Insightful)

      by borud ( 127730 )
      the cover of the reviewed book is good and the fact that the reviewer thinks otherwise makes me unsure how to interpret his review.

      Is this a person who spends a lot of time reading technical books?

      recently a friend of mine published a book. a pretty serious technical book and by my estimation one of the better books I have seen on the topic.
      the problem is that if I saw this book in the store, I would probably just give it a cursory glance and never even bother to take it off the shelf to leaf throu

      • it scares me that I DO judge a book by its cover, but I do. all of us do.

        For instance, I judge cereals by the cover, a whole new box. Now bearing in mind a box of cereals fills that quasi-intimate moment where I am still half awake, and I lovingly spoon it into my mou... oh, sorry.

        You see, books have to be appealing to us, technical books have to say, read my witty and easy going words, and you will be amused and infused!

        In a semi-related issue. In the new world of e-publishing, we see the internet is
  • ...that some buisness need to read. The local school system here runs Blackboard [blackboard.com] which seems to use Apache Tomcat, and it really has problems, both with sessions and general speed. Perhaps some bigger corporations shoudl go back-to-basics with nice books like these.
  • From TFA, it seems tha book is quite basic. Would be great if it would actually discuss "how tomcat works, internally", something like a really advanced course. The material in book can be found in tutorials and stuff, but its slightly more difficult to figure out for the first time that you can "precompile" the jsp pages so the site is fast right from the very first hit.

  • A Microsoft Defender Speaks Out (Score:4, Interesting)

    by INetEngineer ( 816350 ) on Monday November 15, 2004 @06:19PM (#10824433) Homepage
    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.
    • LOL, applications in Tomcat are supposed to be "disasters" from tiem to time! I was writing code on early versions of Tomcat and had a few problems that really caused pain, but overall liked the slim "footprint" on my system and it generally was fast (esp if I pooled some of the heavy-er weight objects).

      Sadly, I'm out of coding now, but it was fun. I'm suprised to hear an MS guy going to Java/Tomcat (I assume Linux as well), most of the MS-guys I know are pretty hardcore. What's the driver here?

    • I think one of the great things about Tomcat (and the specs behind it) was it brought web development and some new development concepts to the Java masses and also to MS. I started using it back in 99 and while it could be a pain to configure and integrate, servlets were a joy after the grief of ASP. MS has taken on some of these lessons and I have to say ASP.NET is some funky stuff. The combination of Tomcat 5 and the next struts version should make an interesting competitor though.

  • help wanted (Score:1, Offtopic)

    by Doc Ruby ( 173196 )
    Have you got Tomcat development experience? Automating Open Exchange? Want a job? Reply to my journal [slashdot.org].

  • How does it compare to OReillys book? (Score:5, Informative)

    by Anonymous Coward on Monday November 15, 2004 @06:27PM (#10824493)
    Anyone know how this books compares to the O'Reilly book, " Tomcat: The Definitive Guide [slashdot.org]"? 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?
    • 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 [sysdeo.com] has a great one that lets you run it in the debugger, with hot-code replace and everything
    • 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.
    • http://www.sysdeo.com/eclipse/tomcatPlugin.html The Hermit as in Geek
    • 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-
    • Yep in production for the job (Fortune 50 Utility company) I just left - both internal and external sites. Also working for Major Financial institution and using it in production there are well. Fwiw, moved from Weblogic at previous job to tomcat.
    • MyEclipse J2EE Workbench (yeah, it's a mouthful) was a somewhat decent plugin for Eclipse when I tried it. Not free, but it worked.
    • I just completed an evaluation of the leading servlet engines for my employer, including the fabled Resin, and Tomcat 5 came out ahead in nearly every respect. It even had a 16% - 20% performance boost over Resin. We couldn't believe it ourselves... If you weren't considering Tomcat because of outdated opinions, it's time to take a second look.

  • Would have been nice (Score:5, Informative)

    by suso ( 153703 ) on Monday November 15, 2004 @06:27PM (#10824503) Journal
    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.

    • Re:Would have been nice (Score:5, Insightful)

      by Timesprout ( 579035 ) on Monday November 15, 2004 @07:04PM (#10824830)
      Well since you are doing it for a client do you not have a duty to at least do some research before attempting to install it?

      You say its poorly implemented but yet say you dont know how its works or much about Java. How can you possibly judge the quality of implementation?

      Tomcat is a mature and established technology. There are a plethora of 'getting started with tomcat', 'setting up tomcat' and 'integrating tomcat with your favourite ide' articles available on the web, before even consulting Amazon.

      It is a doddle to install, setting up a site on it takes a bit more time. As with almost all software the documentation could be better but its not like there is not other info available.

      • Having used Tomcat as an SA and now Java developer I can relate to the parent post.

        When I first had to admin Tomcat deployments I found configuring environments very odd. Now that I have to package our products for other SAs I have the feeling that they won't stand much of a chance in changing any live configuration without our guidance. The point is that they should not have to know much about Java to be able to find the correct configuration information.

        Our SAs weren't familiar with Apache httpd eithe

        • I love Tomcat, but have tried at least 10 times to get it working with IIS using the jk2 connector, and have never succeeded. There are plenty of articles around on the subject, but the procedure varies depending on which version of Windows, Tomcat, and jk are involved.

          I'm going to go try again right now, I'll let you know how it goes...

          BTW, Tomcat != J2EE
          • Last time I got IIS and Tomcat talking was after I abandoned the jk2 and went back to the jk connector.

            There are some additional steps including permission setting to get IIS to use the redirector.

            More info here: http://www.rit.edu/~ack5504/tomcat-iis6-howto/tomc at_iis6_resources.html
      • Unfortunately there wasn't much time to do said research. I did do some reading up on how its done, but the documentation was written from the point of view of a Java developer who knew the names of objects that were used (connectors), etc. Having been a sysadmin for 7 years and configured a lot of different web services, like SSI, PHP, mod_perl, ChiliSoft ASP and Frontpage extensions, I can honestly say that the Tomcat installation is obfuscated, where it really doesn't need to be. WAY too much stuff to
    • Wait a second.... you had trouble setting it up? Should have taken a second. You download it, extract it, install it,or compile it. Then run the little startup.sh or startup.bat. Goto http://localhost:8080 and pretty much everything else is done through a web interface (assuming you added an administrator to the user xml file). From the web interface just add your War and whatever other little things you need to do. I semi-simplified the process, but it is anything but complicated. Involved perhaps, but it
      • See, that is what I'm talking about. What is this 'War' that you talk about? You're using terminology that is not in common tech usage and is most likely just related to java.

        And its not just a matter of doing what you said. The client wanted Fedora Core 3 installed, which lacks Java stuff and so compiling Ant alone because problematic. In the end I wound up convincing them to let me install Fedora Core 2, which comes with all those packages.
        • Oh... okay point taken:) If it helps any, a WAR just stands for web archive. It's pretty much a jar (java archive) renamed and contains everything needed to run the program. If your not the programmer for the project then the details of that aren't important, but the programmer should give you a WAR and maybe tell you some database sources that need to be set up. Its not bad, the J2EE platform is very extensive and covers quite a range of capabilities. I can't see any body understanding each area so don't e
        • Well, it *is* a Java web container... you know, JSPs, servlets, etc.? WAR stands for Web ARchive. Similar to JAR (Java ARchive) and EAR (Enterprise ARchive), all Java-specific. You could have downloaded binaries of Ant, too, and avoided compilation.
  • I actually think that cover is elegant.

  • struts? (Score:3, Insightful)

    by iriles ( 35702 ) on Monday November 15, 2004 @06:31PM (#10824536)
    nice. But, I want "How Struts Works." Debuging struts applications is one of the closest things to hell that I've experienced in some time.

    Ishmael
    • especially in an environment where the guy in charge of the jboss deployment couldn't make it run from an exploded WAR file. so every change meant a wait for the compile, zip up into a 1.5meg WAR file, copy it to deployment directory. Jboss then unexpands it and starts deployment.

      you then go through the whole login thing only to find out you screwed the configuration file.

      java/html/struts single handedly killed my love of coding within a year. coded since i was 11, now 33. hardly touch code now even for f

      • Re:what as bad as writing them? (Score:1, Insightful)

        by Anonymous Coward
        Hey man - this isn't a flame, but I have been on projects before where the developers also thought this was the way to develop J2EE. The thing is that you can actually set things up so that developing a lot of your code is just as quick as perl/php. The trick is to use something like Eclipse (particularly MyEclipseIDE.com) which enables hot code deployment. In other words, you edit a file, click save, it is built immediately and deployed .. in my case always before I can hit 'reload' on the browser. Overall

  • Object instantiation is cheap! (Score:5, Informative)

    by Bubblehead ( 35003 ) on Monday November 15, 2004 @07:02PM (#10824813) Homepage Journal
    Contrary to popular believe, object instantiation is quite cheap these days (see Hotspot Garbage Collection FAQ [sun.com] 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.

    • 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
    • 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?

  • maybe it's just bloated? (Score:3, Funny)

    by geg81 ( 816215 ) on Monday November 15, 2004 @07:04PM (#10824823)
    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.

    If that's true, it sounds like it is bloated and not very well designed.
    • 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 f
      • 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.

        It's ironic, though, that Java is anything but FOSS...

        ANd, also I think it was a mistake to force the java solution to be a high level language.

        I don't think that was necessarily bad. What was bad that they completely forgot about their original mission: lightweight clients. A decade later, we have another bloated server-side platform we don't need (Java), and we still don't have
  • I'd really like to see some docs (a book, notes on the web, etc.) for admins.

    I'm not a java developer, I don't want to be a Java developer, but I have users who do.

    All of the Tomcat docs I've seen are written from the developer perspective. I need to be able to set up and maintain a development environment for students where they can work, and that doesn't crash the tomcat server every time somebody makes a coding error. But I have no desire to learn Java, only enough Tomcat to keep it running.

  • Sample Chapters (Score:4, Informative)

    by kyoko21 ( 198413 ) on Monday November 15, 2004 @07:32PM (#10825056)
    You can read some sample chapters here [brainysoftware.com]. Just use your favorite archiving application and acrobat reader(neither included).
  • 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.
  • Comment removed based on user account deletion

  • Tomcat is NOT a J2EE server (Score:5, Informative)

    by danwiz ( 538108 ) on Monday November 15, 2004 @10:47PM (#10826428)
    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 [jboss.org] is an example of a J2EE compliant app server.
  • By comparisson Tomcat is one of the best and quickest servers to run J2EE, servlets and JSP (it is also the best static content server around, Apache you know).

    I have used many other java application servers and they don't really come close. WebLogic dev environment and stability made me appreciate a root canal. WebSphere taught me patience while waiting for the debugger to start (if it doesn't crash while starting); not to mention the debugger can easily use up 1GB of ram while running. iPlanet, well I

Slashdot Top Deals

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Close