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"
"As if we didn't know" by CmdrTacho is a goatce.cx link. And it's not even well designed, the text that says "goatse.cx art gallery" or whatever loads way before the graphics.
Be the Ultimate Ninja! Play Billy Vs. SNAKEMAN today!
From what I hear Java/java programmers seem to be in less demand these days. Many H1 visa holders with java skills are being asked to go back.
There's always sufficient, but not always at the right place nor for the right folks.
i've been using tomcat for the past couple of months and have found it to be very! buggy, it frequently fails to recompile jsp pages when changes have been made, and can't handle includes correctly. more worrying is that it dosn't clear out it's bufferes properly, so you can get part of a previously view web page back before the one you have requested. 'DONT USE TOMCAT' if you have any security requiremets!!!!
thank God the internet isn't a human right.
For information on tomcat, check out the tomcat site and an example of a default tomcat page.
The article begins "One way to learn to deployment Tomcat web applications is to explain fully the steps required to deploy a Tomcat web application manually."
What kind of English is that? I don't usually nitpick over grammar, but when there is stuff like that going on in the first paragraph I have to wonder if the rest is worth reading.
Need XML expertise? crism consulting
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
If you're developing a commercial JSP application the go with Allaire JRun. It's damn fast, easy to setup, reliable to the extreme, scalable and the EJB bloat doesn't get in the way like application servers from BEA, IBM et al. Jason.
Wow, ads from big corporations. Why the fuck _would_ they post such a lame story?
Actually, a similar story was posted on /. recently (about IBM's Linux campaign). They didn't have any sample ads at the time, but I guess somebody scanned them. I don't think it's lame at all.
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...)
-
Tomcat blows goats. I suggest you try Resin (www.caucho.com) or Orion Server (www.orionserver.com ). Both of them are superior products with superior support. All my experience with Tomcat was a nightmare, and i have been using it for quite a while. And it's documentation is too old and FAR from complete.... And speed ... extremely slow.
igor (at) linuxinside (dot) com
In O'Reilly Network's "Using Tomcat" series, author James Goodwill previously has explained how to install and configure Tomcat.
is this gonna hurt?
entertain me with java
Feed The Need[goatse.cx]
"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.
I've got a lot of experience with JSP/Servlets and Weblogic, and now with Tomcat and Apache. I've found it to run extremely well, and really wasn't that hard to install. What I like about it is the price. In fact, Tomcat makes we wonder why we paid such an exorbitant amount for Weblogic originally. I was surprised to hear all of the negative comments.
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.
Smeg.
Don't ever post when you've just woken up.
--
The more I learn about the Internet, the more amazed I am that it works at all.
A few months ago our company evaluated several jsp/servlet engines, including tomcat, and the only one that was even remotely usable was one called Resin
I'm just getting back into Servlets and a friend recommended I try orionserver. He said it is stable and easier to configure. He was right. According to the benchmarks posted on their site (www.orionserver.com) it is also faster than everything else. This is good enough for me because it is free for my purposes.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~ the real world is much simpler ~~
--- -- - -
Give me LIBERTY, or give me a check.
Not a direct link I'm afraid, but check out the "realated sites" on JESS which is an experts system shell. There were some agent pages there.
Also for basic stuff you might want to check some pages about general agent programming from an AI standpoint.
I had to use Tomcat for about 3 months last year at a dot-bomb and was not impressed. As evidenced by this tutorial, there are too many steps to setup the thing. I also found it to be unstable on Win2000 and Mandrake Linux. I hear and read that it is also very slow compared to other products.
Recently a friend suggested I install a free download of OrionServer (www.orionserver.com) because it was easy and is also an EJB container and all that stuff. I was skeptical, but damn --- it installed and configured in 3 steps: 1=Download, 2=Unzip, 3=Run orion.java. (Their tutorial is 1 paragraph.) Why isn't Tomcat clean enough to install & configure like that?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~ the real world is much simpler ~~
--- -- - -
Give me LIBERTY, or give me a check.
I use Tomcat and I love it! Wanna know why? It's 'coz I use it to test my JSPs and servlets - IT IS A REFERENCE IMPLEMENTATION AND NOTHING MORE!!!
When it comes to deployment on a "serious" scale, use a commercial J2EE-compliant AppServer, such as Sybase' EAS, WebLogic, WebSphere, iPlanet, etc.
If you have to use Tomcat in production, you can improve it yourself or pay someone to do it for you - it's Open Source!
How python can be used with your existing JVM
Java and Python Side by side
The story of a java program turned into a python program
Your millage may vary
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.)
It is small and very easy to install and configure. It can easily be embedded in a larger Java application, allowing a Web interface to be added "after the fact."
It is supposed to be as fast as Resin. Probably means they use similar techniques.
I'm still trying to figure out what people mean by 'social skills' here.
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.
We finally bagged crappy tomcat and switched to Resin. My god: it was like switching from dreid lentils to yummy ice craem. Takes all of 30 seconds to install, it's been completely reliable, easy to configure, even SSL worls great!! And the best thing is: it's fast as hell. We did benchmarks. Beats every servlet engine, and best of all, is much much faster than PHP or mod_perl. Try it!
"It must be something truly enormous, Trismegistus"
Tomcat is also a web server itself. The Apache (or many other web servers) integration is optional (but quite beneficial as Apache is much more flexible for serving static content).
Donate free food to the hungry at The Hunger site.
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.
I'm also interested in investigating Enhydra.
For more info on Java servlet tutorials, ect. check out 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.
Don't question the /. orthodoxy without a little elaboration, boss.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I otherwise agree 100% that some Slashdot readers are generally ignorant that B**w*lf is not the be-all and end-all of scalability, and that wooden frames, while suitable for houses, are unseen in very tall buildings.
-jhp
/. -- the Free Republic of technology.
apache jserv is now more or less handled by the mod_jk. the beauty of it all is that you can still have apache to do the usual stuff, and then use tomcat to handle JSP files. mod_jk looks at the request coming into the webserver, and if it qualifies (e.g. index.jsp), it will redirect the request to the tomcat running, independent of the apache server. AFAIK, that's what apache-jserv does. it's not great, but it makes everyone happy..
and no, it's quite alive and well.. and rewritten from scratch.
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.
The hosting company for my vanity site uses Resin as its JSP/Servlet Engine. I've found that caucho's XML implementation is incompatible with Apache's Xerces and Xalan, unless you put apache's jars before in the classpath. Yes, resin has its own XSLT engine, but I'd like to be able to use whatever I want (cocoon, for example) without annoying the support staff. I've tried xalan in other servlet implementations and it worked flawlessly in all of them. Resin may be fast, but it's inconvenient for me.
Victor
i think enhydra uses tomcat code. some of the exception trails seem to support this...anybody know?
please! if you look through the millions of lines of code you'd probably find a kitchen sink in the Windows kernel too...
Tomcat is a OpenSource and is covered by ASF umbrella. In the bench the Tomcat used was 3.1, we're now at 3.2.1, 3.2.2 to come, which are faster and more stable. Upcoming 3.3 Tomcat is also much more faster, nearly the speed of Resin :)
Please take a look at Tomcat 3.2.1 or better wait Tomcat 3.3 and we'll speak again about speed. If you're a Linux Redhat users, installing Tomcat and making it run is no more harder than : rpm -Uvh tomcat.... /etc/rc.d/init.d/tomcat start
And there is also Apache connectors in RPM,
rpm -Uvh tomcat-mod...
Tomcat is ASF, and is supported by Sun team...
Servlets that work with JServ will work with tomcat just fine. Why not keep using JServ until tomcat's readiness is more to your liking?
apt-get install jserv
still works for me.
In The Problems with JSP, Jason Hunter, author of the O'Reilly servlets book, paints a different picture from yours about how well JSP serves to make the front end "as purely HTML as possible." Apparently it's quite common for JSP programmers to break the clean separation you describe.
Such non-separation is totally understandable. There are times in a product development cycle when you want to do quick prototyping, and it's convenient to put code right there in the JSP. Problem is, once it gets in it's hard to get out. You have to come up with a class hierarchy and wrap an object and method around the code that you cut out of the JSP. This is doable, but not convenient.
Generally projects have to choose up front whether to go with a rapid prototyping tool like PHP or a strictly structured environment like WebMacro. Or they can go with JSP and have some release management structure in which coding standards are enforced.
Alternatively, they could use BRL for rapid prototyping. If the project grows to require more code separation, it's easy to wrap a procedure definition around code cut from a page, then put that definition in sitedefs.scm. You can make use of all kinds of Java objects as well, though you're encouraged to keep Java-specific code out of individual pages. BRL is not intended to be Java-specific, although the current implementation is.
it's slow as molasses. But, it's neat cause it's java.
MySQL is *NOWHERE NEAR* as robust and evolved as Oracle. Don't dilude yourself. That doesn;t mean MySQL sucks and Oracle rulez. It simply means for some tasks, you have no business using MySQL. Ex: Anything involving transactions.
-Calin
we're having the opposite thing happen with us. Our developers (web and otherwise) are moving from C++ to Java, since it's a cleaner language, code's written faster, and they have the option to clean it up enough to run on more than just Windows (they have to clean since our other main platform is Mac OS 8.x, which runs old Java). Oh, and they love using it. No garbage collection or the like. Yes, the speed ain't there, and they are mainly writing for the server, not the client, but I don't see Java going away. Heck, most colleges I'm aware of are moving from Pascal (as an intro language) to Java.
"Sometimes a woman is a kind of religion, she can save your soul & set you free from all your sins" - Bad Examples