Slashdot Mirror
Apache's Jakarta-Tomcat Server Explained
Ellen writes "Apache's Jakarta-Tomcat server is an open source, Java-based Web application container that was created to run Servlet and JavaServer Page (JSP) web applications. In O'Reilly Network's "Using Tomcat" series, author James Goodwill previously has explained how to install and configure Tomcat. His latest article provides in-depth information about how to deploy it.
Read "Deploying Web Appliactions to Tomcat"
it's got everything you need in one very easy to setup package. And it's faster than tomcat, and without the annoying bugs (such as pages not recompiling when you update an included page...)
-
When I read about PHP vs. Perl vs. Java or in this case, about Java servlet & JSP engines, it really bothers me that so many people totally miss the point.
:)
How you embed a couple of variables into the HTML is a complete non-issue. PHP, Perl, JSP, servlets, ASP, they are all fast ENOUGH and in all of those, it's easy enough for anyone to do. It's completely irrelevant anyway if the response time is 0.1 or 0.3 seconds, even if that's a 3x difference. Even if one technology would mean you have to get 3 servers instead of just one, hardware is so much cheaper than developer time that it's still worth it. There are *major* sites running all of those technologies I mentioned above, which is proof enough that they all scale and the fact that there are supporters for each also proves that for different people, different technologies are differently suitable.
The real "problem" is how to separate logic well into "something else" and have that "something else" communicate to the front end layer (the ASP, JSP, PHP, Perl etc.) the results so that you don't end up with a back filled with HTML where you should only have logic. Also, how does that back end scale *conceptually* as the application grows more complex? Is it a pile of spaghetti code or does the technology / language promote good design? How does it integrate with existing systems and databases?
100 line "benchmarks" don't answer those questions and the myriad of clueless Slashdot posts from people who have never actually done anything more than a "hello world" will also not answer the questions.
Now here comes the controvercial part; in my experience, Java is miles ahead of the rest (ASP + COM is about on par if you are working on something that just has to run on an NT server) when it comes to real world application development. The main reason is that the front end and back end communication is so great. JSP is clearly a better model than servlets as the front end should be as purely HTML as possible. The fact that JSP allows you to make up your own tags and map them to Java code also makes it really easy to do more complex stuff - all tag based (this is why Cold Fusion is so popular among non-techies).
Still, JSP compiles into Java servlets, which is a great model from a programmer point of view (one instance, one thread per request etc.) so you get the best of both worlds - clean HTML and a great programming model. Also, since a Java servlet is a normal Java class, your can build an application out of it really easily and use all the stuff you would normally use - EJB, Corba, RMI, JDBC, etc.
The object oriented (sorry, object based) nature of Java also promotes good application design so that you don't end up with a huge "MyPortal.cgi" Perl script with 50000 lines of code and HTML, all mixed up into one big mess.
That Java is "running" and that only new threads are created for the requests also gives you the benefit that you can do things like caching in-memory between requests etc. really easily. This again makes it possible to employ all kinds of techniques for speeding up sites, bypassing database queries for often-requested stuff etc.
This is just my point of view though. I'm sure others consider Perl a better alternative and have a lot of reasons to back it up. I'm sure they can list a lot of technologies that I didn't know of (Perl related I mean) that lets them do basically the same things that I just described above. This doesn't bother me at all - quit the opposite. What bothers me is that Slashdot (and IBM) posts idiot stories about "comparisons" that don't mean anything since the real problem is not in the front end.
That's all.. My rant is over..
I'm kind of hoping that Tomcat dies a fiery death. Maybe then someone will go back and resurrect Jserv.
...
Actually, JServ is being resurrected (sort of), as Tomcat 4.0.
The Tomcat project hit a serious stumbling block when Sun contributed the code for Java Web Server, which became Tomcat 3.x. Development pretty much stopped, waiting for them to turn over the code, which turned out to be of very disappointing quality. Early 3.x releases of Tomcat were very shaky, and has given the project a bad rep. A lot of work has gone into improving the 3.x line, which is getting pretty damned solid with recent releases (3.2.x).
The original plans of the JServ team for its next release, Catalina, have been resurrected and are in beta as Tomcat 4.0.
It's a shame that the earlier releases have given the project a bad rep. It's a useful case study for open source projects, and also a good demonstration that commercial code is not always better than open source code. Since they don't let you see what goes on inside the kitchen, you assume it's a professionally run operation with great sanitation and QA, but
-- Sigs are for losers
The issue with tomcat is much more complicated than whether tomcat is a good product or not. Tomcat is born into a political problem in the open source community. Jserv grew up to compete against Tomcat. Tomcat was a pay for product from Sun. Sun decided that they wanted to hand it over to Open Source. Sun's philosophy has been that they are a computer manufacturer, not a software house - and any software that is really good - eventually they give away(My opinion - think NIS, RPC, NFS). The Open Source community was faced with a bifurcation of efforts - with Sun willing to commit resources to building Tomcat. The folks involved in Tomcat/Jserv chose to join forces into a single version of tomcat to not duplicate efforts any more. The results of this union are just now starting to show up as enhancements in the tomcat code. My experiences with Tomcat were as frustrating as other people's - But ultimately it came down which version of Tomcat was being used - the simple fact is the close you are to the development version - the better the tomcat product. I discovered that the 3.3 line seemed A) MUCH FASTER B) had better configuration stuff. I think this is a healthy sign - while many commercial products may be better at the moment - I'm willing to bet on the momentum of well designed code, with strong refactoring by many developers, to eventually bring out a superior product - one that no one can compete against. The 3.3 line, in my opinion, is on par with the jserv implementation, if not slightly better. -Tom Riemer tom@58k.com
I'm surprised at all the negative comments about Tomcat. I use it for a production site that gets ~35,000 page views/day and have found that all the bugs I THOUGHT were tomcat's were actually mine.
What you're seeing here is what happens when people who are spending their company's money and meeting their company's deadlines need a solution. The best thing about tomcat is it's free software. That matters very much if you're trying to create something wonderful. It matters less if you're building something that your boss told you to.
d
"Why aren't they out arresting dope dealers?" --Carmella Soprano, on being pulled over for a speeding ticket.