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.
or do java apps take up a huge amount of system resources? Everytime I launch one, my system crawls.
Look, I used to hate Java, and quite frankly I can't say I love it much yet. But to be honest, it's come a long way since the days it was unbearable. So please come off the Java bashing, it's passé. Either that or upgrade your system for crying out loud...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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
its, not it's.
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.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Ehrm, technically, yes. But I'll be damned if I could get the thing to be stable when I tried to set it up.
See, at my (brand spanking new) dorm, we needed a homepage. So this dude volunteers to make one, and is sent off with the words "It must work on a standard Linux/*BSD platform. No proprietary crap, please." A week later, he shows us this impressive thing running on his laptop. Only problem is, it runs under Tomcat. So I try my very best to get this thing running on our FreeBSD box, before abandoning it, and just have someone build it with PHP instead. Lessons learned working with Tomcat:
- Documentation and support is near non-existant.
- The thing is slow as molasses.
- It crashes for no reason, even while not under load.
It might very well be that I am completely incompetent, but for the most parts, I have succeeded in getting stuff up and running once I set my mind to it. But this piece of software does not exactly have my warmest recommendations.Just one mans experience. You mileage probably varies quite a bit.
I think of it this way... PHP for web applications is inevitably like building your own house from scratch... mixing the concrete, cutting down the trees, etc. All by yourself. As I've developed some web applications in PHP, this is acceptable if you're building a yurt or something.
Java servlets are what you want to use if you want to ensure some level of expandability, or at least standardized web development practices (in theory). Companies generally don't have one mega web application they run, they have anywhere from several to dozens. You don't really want to start from scratch there. Authentication? Yeah, servlets can do that. Flow control? Yeah, that's covered too. In general, if it's something you're probably going to need, the specification covers it and you can implement it based off the specification, as opposed to winging it. Or, to get back to the house thing, buying precut steel instead of making it yourself. Or, having ready-made shingles instead of copying a design that was made earlier that may be kinda shoddy even though you don't know it.
This doesn't necessarily knock down existing frameworks like Ruby on Rails, which looks pretty sweet, or anything with frameworks. Servlet containers just happen to be (more) secure, time tested foundation from which to build web applications. Tomcat is a good servlet container. We also use BEA WebLogic.
-Rob
Marriage doesn't have to suck!
We payed hundreds of thusands to have MS and third parties try out their best stuff on our intranet. At the end of the day, MS didn't have anything that could compete with PeopleSoft HR and PeopleSoft Portal. The MS solution just didn't fit our needs, it cost more and was less flexible. The PeopleSoft arch we have is Java based and runs like a champ for 140,000 employees at our corp, not to mention hundredes of thousands of others that PeopleSoft have sold to.
I am sure you can take your MS-Only "deveolpers" and build a "great" corp. A bunch of "VB-Only" type "developers" whos knowledge in development is limited to a paper bag, that would be such a great foundation to build on. Please name any _major_ MS innovation that MS has come up with themselves that had no influence from some prior art?All of the biggest corps in the USA (including the one I work for) have non-MS servesr running because MS doesn't have software that can even compete with the competition.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
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, for the stuff I spend most a lot of time doing (Implementing business logic within one method) this is a hell of a benefit. For the other things, including refactoring or adding new methods .. you might still need to restart but I think this is being rectified soon ... .. my goal is eventually to have my whole OS running inside one, compact and highly effecient (less context switching!) process - Apache.
Oh yeah, to anyone reading this - any knowledgable developer does not code in Java because of it's syntax, it's goodies (as if it really has any) or any of that shit. Most people use Java for the same subleties you might use Linux over another OS - it has more community, it makes more moves in cool ways than other technologies, has a HUGE amount of things written directly for it, it has been widely supported in a fashionable and productive way, to name a few. I will actually freely flame the guys that use what is honestly _not_ an application language (perl or similar) for application tasks. There is a reason that no case tools support perl, that there are no proper web application architecture documents written for it and in particular no extensions written for it that are even in the same category as JSTL/JSF/etc. I once went looking for a 'good' web MVC framework for perl/php/etc... only to find a single one that didn't even really compare to the 100s out there for Java. Finally, please get this straight - Apache is a great WEB server - not a great Application server. The preference to not seperate out the tiers is baffling, truly. Hell, I am thinking about making mod_mysql which will embed the mysql process inside the apache process too
pHEAR.
Sincerely,
zed m.
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 through it. seriously.
I read a lot of books and I would hate to waste time on a book that isn't worth my time, so of course, I have to be selective. the cover is the first criterion by which I screen books, and I doubt that I am unique in starting there.
it scares me that I DO judge a book by its cover, but I do. all of us do. there is no way you can read through the TOC of hundreds of books when you visit a well-assorted book shop in order to make a more thorough judgement on a book.
O'Reilly seem to have understood this. their books usually have a sober, tasteful look about them, and it is somehow an irony that the average quality of an O'Reilly book has dropped in proportion to the degree of overall variation in cover design (I am not saying that the quality of an ORA-book is inversely proportional to its deviation from the "formula", but that it holds for ORA's annual output as a whole).
still, the no-bullshit, calm, and sober look of O'Reilly books make them a natural focus point in any computer book section. (that and the fact that their predominantly white covers stand out. how come the cover-designers of other publishers seem so ignorant about the use of colors?)
yes, the cover matters, and despite what the reviewer thinks: the cover on the reviewed book does it no disservice.
what IS questionable about the book is the fact that it has many spelling mistakes. this suggests that the editor has not done his or her job putting the book through even the most basic quality assurance, which in turn means that there could be factual errors in the book, which for this kind of book is really, really bad.
this would make me reluctant to shell out $50 for this book.
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 a decent, sandboxed client-side language (only Flash).
IMHO, the whole direction had completely thrown KISS out the window - either me or them are going insane.
The problem is with Sun and Sun's direction: they couldn't make thin clients work within a couple of years, so they changed course. If Microsoft had been in Sun's place, they would have pushed harder and longer, and they would have made it work.