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"
For information on tomcat, check out the tomcat site and an example of a default tomcat page.
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...)
-
In O'Reilly Network's "Using Tomcat" series, author James Goodwill previously has explained how to install and configure Tomcat.
is this gonna hurt?
"In order to live free and happily, you must sacrifice boredom. It is not always an easy sacrifice."
I'm serious - this is a sign. I need to ween myself from slashdot.
--
Vidi, Vici, Veni
A couple of years ago, I headed a project that we deployed via servlets, and used the Apache Jserv engine as the platform. Simple, stable, good performance. We deployed the app, and had no trouble. Everyone was happy.
This year, I was looking to develop another servlet app. I saw that Jserv is no longer under development, and has been "replaced" by Tomcat. Holy crap! what a reversal of fortune. It wouldn't install, the configuration is so complex that a degree in advanced illogic is necessary, it's unstable, and it doesn't have the feature set that a two-year-old version of Jserv had. In short, it's completely unusable. But, because Jserv isn't in the development path any more, that wasn't a good long-term option either. We ended up abandoning Java entirely as an option, since we didn't have time to evaluate other engines.
I'm kind of hoping that Tomcat dies a fiery death. Maybe then someone will go back and resurrect Jserv.
JServ came into being because there was no existing way to tie a servlet environment to Apache via a module. However, it was written for the first version of the Java Servlet spec, and grew out of date as the new versions of the specs were released.
Abandoning Tomcat isn't the answer, and to be frank, it just isn't going to happen. Yes, the 3.x codebase of Tomcat had no shortage of issues, which is just one reason 4.x is a rather substantial fork from it. It's unfortunate there has been a lapse between JServ and a stable Tomcat, but it's only a matter of time (Brief, we hope) before 4.x leaves the beta stage and provides a stable Apache module interface.
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..
(Disclaimer: Not a paid endorsement.)
-jhp
/. -- the Free Republic of technology.
Tomcat is the reference implementation of the most recent Servlet/JSP standards. As such, it has undergone very little optimization, and isn't particularly friendly to administer. Scratch the surface of anyone who's had to run Tomcat, and you'll find someone who's had a variety of CLASSPATH, speed and reliability problems.
<p>Don't use Tomcat in anything but a development environment, or to test things against the standard implementation. There are many free and non-free alternatives available.
<p>The whole point of the J2EE standards is that the techniques that you can use to deploy an application on Tomcat should work on <i>any</i> J2EE compliant servlet container. The webapp filesystem layout Tomcat uses, which is explained in this article, is really just a Sun standard available on most modern java application servers.
<p>Charles Miller
--
The more I learn about the Internet, the more amazed I am that it works at all.
Aquiring more skills in general is wise. The people that are less in demand these days are the people that failed to do so. Unfortunately a lot of so-called webdevelopers with little or no professional training fall into this category.
A good Java programmer (or any good programmer) will have little difficulty moving to another language.
So in short, if you are still wondering whether Java is worth the trouble for you, I strongly suggest you either start learning Java or pick up one of the many alternatives (C++, smalltalk, whatever).
Jilles
Thats funny. I'm using 3.2.1 and it works great here. None of the problems you describe have surfaced. It provides servlets/jsp/cocoon pages for a medium sized university (where I work).
In the least it is much faster than our perl cgi scripts.
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.
I'm currently programming a servlet-based frontend to a backend XML stockbroking system; the final system is to be deployed on a BEA WebLogic server (http://www.weblogic.com/), but I'm using Tomcat as a servlet environment for development I do at home.
I didn't find Tomcat all that difficult to set up, once I threw the instructions away. When I first attempted to install Tomcat, I spent hours picking through instructions on what to change in httpd.conf (to get servlet requests on port 80 directed by Apache to Tomcat), what to change in Tomcat's server.xml, and any other number of configuration files. If anything, I found the instructions to be misleading - on just looking at the config files and using some common sense, I didn't find it all that difficult to set up. Especially considering that a quick Google search on whatever startup error you get almost always turns up some kind of e-mail list correspondance with someone also having had the problem, and someone else presenting a solution.
In addition to this, you can just run the Tomcat startup script ([install_dir]/bin/tomcat.sh), and Tomcat will begin listening for requests on port 8080 out of the box, which I found was easiest if quick and easy setup was the goal. It's only really in redirecting port 80 stuff to Tomcat that things get tricky.
On the performance / stability issue, I've not found Tomcat to be inferior to any other servlet environment, in almost every respect. It is true that sometimes it would have to be restarted when only simple modifications had been made to a web app to get the modifications to deploy, and these cases never seemed to be consistent with any particular environmental state, but I didn't find that this occured with enough frequency to be considered a great problem (not that the problem shouldn't be fixed in any case).
But yeah - I've not had the chance to see it being used yet in a non-development environment, but my experiences with Tomcat would not dissuade me from recommending it to someone looking for a reasonable free servlet environment.
- SMJ - (It's not just a name: it's a bad aftertaste.)
Catalina is a fork from the Tomcat 3.x code, it has no origins in JServ. One thing they do have in common is that the guy that forked Catalina was part of the JServ team for quite awhile in the years prior.
I'm a JavaNewbie, but I installed Resin in very little time and have it up and running on a beige Mac G3 LinuxPPC box. Now I'm looking into installing and configuring servlets (like those found at CoolServlets). I'm one of the people who hated Java because it was slow, but don't blame the language for the client-side problems. This URL says it all better than I could: http://www.davidreilly.com/java/java_network_progr amming/#6.
If you are a newbie like me and interested in learning more about Java/Servlets/etc. you'll find lots of links at my blog: Brainspatter.
Curious__George
***General Consultant to the Human Race*** My opinions are free. You get what you pay for.
Resin beats the pants off Tomcat according to third party benchmarks.
Curious__George
***General Consultant to the Human Race*** My opinions are free. You get what you pay for.
I am a resin user as well. Better support, better feature set, faster. Much better than tomcat.
JRun was a good server in the early days, it has been far surpassed by Resin (from Caucho - www.caucho.com) in speed and flexibility. Resin's XML/XSL-T implementation wipes the Apache's stuff right off the floor as well.
Does anybody care to pick all the errors out of that guy's reply? With a little luck we can exponentially crapflood the internet with discussions about grammar.
Need XML expertise? crism consulting
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Cool.
Need XML expertise? crism consulting
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?