Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Java Programming Software Apache

Apache's Jakarta-Tomcat Server Explained 91

Posted by Hemos from the looking-under-the-hood dept.
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"
This discussion has been archived. No new comments can be posted.

Apache's Jakarta-Tomcat Server Explained More

Apache's Jakarta-Tomcat Server Explained

Comments Filter:
  • "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.
  • Perhaps you should have waited for the graphics to load. It's very fine arts.
  • 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.
  • 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!!!!

  • Relevant links (Score:3)

    by Bi()hazard ( 323405 ) on Saturday April 21, 2001 @08:49PM (#274784) Homepage Journal
    For information on tomcat, check out the tomcat site [apache.org] and an example of a default tomcat page [4.40.164.78].

  • 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 [maden.org]
  • 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.
  • So what's the verdict? Was it worth reading?

  • Re:Since Hemos wont post it (Score:1)

    by Anonymous Coward
    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.

  • i prefer Resin... (Score:4)

    by rebelcool ( 247749 ) on Saturday April 21, 2001 @09:22PM (#274790)
    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
  • It's true. Java development is slowing down. I'm looking for a job now, and that's what all of the recruiters are saying.

  • At the time I'm writing this, the fortune at the bottom of the page says:

    "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.

    --

  • 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 served its purpose. Tomcat is the next step (Score:3)

    by Cardinal ( 311 ) on Saturday April 21, 2001 @11:13PM (#274798)
    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.
  • In my opinion there is a better article about this by Reuven M. Lerner in Issue 84 of Linux Journal. It may be worth the time to find a freind who has the issue.

  • JSP & Servlets are only part of the problem (Score:5)

    by macpeep ( 36699 ) on Saturday April 21, 2001 @11:51PM (#274800)
    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.. :)

  • Re:Tomcat vs. Apache Jserv (Score:4)

    by NullAndVoid ( 181397 ) on Sunday April 22, 2001 @12:02AM (#274801)
    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 ...

  • Resin [caucho.com], while not quite open-source, is an amazingly low-cost yet highly scalable web server platform. Ir does an admirable job of serving Java applications redundantly and implements a goodly portion of the relevant Sun standards with easy configuration and mediocre documentation. I recently developed the infrastructure of a mixed JSP/servlet image-delivery web application (no, not what you think) using Resin and it was relatively easy to deploy, stable, and demonstrably 2-4x faster than Tomcat. Resin had very few but but nonetheless surprising holes in coverage, like ignoring startup order in web-app/load-on-startup tags. Resin is an order of magnitude cheaper than Weblogic or Dynamo, and you even get the source (which BEA and ATG jealously guard).

    (Disclaimer: Not a paid endorsement.)

    -jhp

  • <p>Tomcat is the <em>reference implementation</em> 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
    --

  • Smeg.

    Don't ever post when you've just woken up.
    --

  • Re:i prefer Resin... (Score:1)

    by Anonymous Coward
    Absolutely, Resin is a superior product all around. I work for a certain company that invented Java, and have been working closely with all the major servlet containers for the last year and a half.

    Tomcat, while not the worst of the lot, is pretty bad. In Tomcat 3.1, which was the stable version for months and months, the ability to use RequestDispatcher.include() to include other content was utterly broken, with no fix in sight. That didn't give me a very favorable impression, even more so after reporting the bug on the devlist and getting no replies or even confirmation that they knew about the problem.

    After testing against Resin for a year, my opinion is that it's absolutely the best basic servlet container out there, and it even offers quite a bit more. Other products offer other features, such as clustering & HA, but the technology behind them isn't nearly as clean or as elegant as that in Resin. Nor are they anywhere close in speed--the author of Resin worked for Sun performance tuning web software for Solaris.

    In the end, forget Tomcat, it's another victim of open source; buy Resin--it's cheap, superior, and deserves to come out on top.

  • Resin (Score:1)

    by Anonymous Coward
    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 [caucho.com]

  • Re:Is aquiring more java skills wise? (Score:3)

    by jilles ( 20976 ) on Sunday April 22, 2001 @03:05AM (#274807) Homepage
    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).
  • You should really have a look at zope [zope.org].
    It's object based, based on python (also OO) and also supports multiple inheritance, which is very handy for factoring you application into small components (classes), which "lend" their specific capabilites to your application's objects via mixin classes. This is very nice to seperate "orthogonal" capabilites into different locations (classes).
    You get all the facilites of java you mentioned above with zope.
    A good overview about the theoretical aspects of zope (and more) can be found at http://www.dieter.handshake.de/pyprojects/zope/boo k/chap3.html [handshake.de].
  • Sounds cool.. How does Python stand up to Java speed and stability wise (especially on various platforms - not just one particular)? I've been thinking about learning some Python but so far, I haven't really run into any situation where I would have really needed it.. I also haven't really found Java to be a problem - not execution speed nor development speed wise.
  • Bah, don't believe it! I've gotten Tomcat up and running in an amazingly short amount of time on many occasions. And it sure beats the pants off Jserv :)

    Mmmmmm Sevlets and JSP.... Mmmmm tasty.... Get those servlets doing some data retrieval and those JSP's doing some XML parsing and you got yourself the most amazing platform ever... Mmmmmm...

    Now if only it had an EJB container...
  • 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 [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 ~~

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

  • Not a direct link I'm afraid, but check out the "realated sites" on JESS [sandia.gov] 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 [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 ~~
  • So your employer has something that works, and you want them to pay you to re-write it?

    It sounds like you want your employer to pay for your Java training (in the guise of re-writing something that works).

    We used to call this a "resume enhancing task."
  • Sorry, I have to STRONGLY disagree on this point. I do Java development at a large financial institution, and we have decided to stop using JRun due to some rather significant problems. For instance, under certain conditions, creating a reference to a session object can totally hose your application on the UNIX version (same code executes fine on NT, funny huh?). We also had problems with the NT version sometimes throwing "Bad Magic Number" exceptions (you can resolve this only by deleting the compiled servlets and servlet source, go figure). While bugs are to be expected with any platform, I highly recommend Tomcat as it is in my opinion, quite stable, and seems to be a standard as far as embedded servlet engines go for many of the third party applications we use (rule engines, workflow engines, etc.). I do agree that JRun is easy to set up, but for a commercial application, it is probably worth the effort to set up and configure a more stable and less buggy platform.
  • There has been a cutback in the overall demand for internet development skills. Java is the number 1 most in demand internet development skill, thus there has been a cutback in the demand for Java skills. This has no implication for the demand for Java skills vs competing technologies. Marcus
  • You might want to check out jboss [jboss.org]. They've got an active community and a pretty good container.
  • so go to jboss.org and examine their *already bundled* aggregate of jboss+tomcat or jboss+jetty...

    it's quite stable, extremely well engineered, and may just be my favorite container... (still a few things that i'm not entirely sold on, but the rationale is starting to sink in)

    cheers.

    Peter

  • Tomcat is not full-fledged product! (Score:1)

    by Anonymous Coward
    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!
  • When my friends ask that question, these are usually the 3 links I give them.

    How python can be used with your existing JVM [google.com]

    Java and Python Side by side [twistedmatrix.com]

    The story of a java program turned into a python program [twistedmatrix.com]

    Your millage may vary

  • Tomcat (Score:4)

    by Anonymous Coward on Sunday April 22, 2001 @07:49AM (#274822)
    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

  • Actually, it does say something about Java itself, as opposed to the overall market downturn. Java turned out to be a failure on the client and most places that had been designing those awful and slow Java user interfaces are now getting decent work done using Macromedia tools.


    Cheers,

  • Surprised (Score:4)

    by dgenr8 ( 9462 ) on Sunday April 22, 2001 @08:21AM (#274824) Journal
    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.

  • Tomcat: not all that bad (Score:3)

    by tuxedo-steve ( 33545 ) on Sunday April 22, 2001 @08:43AM (#274825)
    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.
  • If you only need servlets and Java Server Pages, I highly recommend Jetty [mortbay.com] from Mort Bay Consulting. It is Open Source/Free Software and is written entirely in Java. It is a Web server in its own right (that is, not an add-on to Apache), supporting HTTP 1.0 and 1.1 and SSL

    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.
  • He's probably refering to "include"ing one .jsp file in another. If the .jsp file being included is modified the .jsp file doing the include won't automatically recompile and will use the old code.

    It's documented, but hey it's much easier to complain about a bug than to read the docs, right... :)

  • Rather than asking somebody else to ressurect Jserv, why don't you do it yourself?

    This is not intended as a flame or criticism, but merely an observation of how opensource/free software developement is supposed to work.

  • 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!
  • 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).

  • Resin: agreed & here's the link. . . (Score:3)

    by Curious__George ( 167596 ) on Sunday April 22, 2001 @01:03PM (#274833)
    http://www.caucho.com [caucho.com].

    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 [coolservlets.com]). 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. [davidreilly.com]

    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 [blogspot.com].

    Curious__George

  • Here are benchmarks: . As you can see [orionserver.com]Resin [caucho.com] rocks. Tomcat blows.

    I'm also interested in investigating Enhydra [enhydra.org].

    For more info on Java servlet tutorials, ect. check out my blog: Brainspatter [blogspot.com]

    Curious__George

  • http://www.jspformacs.com/articles/Resin-HOW-TO.ht ml [jspformacs.com]. Also available in a minty, chewable PDF [jspformacs.com] flavor. (from the JSP for Macs [jspformacs.com] site).

    Resin [caucho.com] beats the pants off Tomcat according to third party benchmarks [orionserver.com].

    Curious__George

  • I am a resin user as well. Better support, better feature set, faster. Much better than tomcat.
  • You know, I'm confused, too...are all these people who are saying "Tomcat is buggy" using the same Tomcat that I am?

    I'm using Tomcat as a servlet engine for a virtual community that's making a comeback after its previous home was shut down, and, in three months of heavy development and testing of some pretty complex server code, I have found exactly one bug in Tomcat itself...and that only when I finally got integration with Apache via mod_jk working. (Which, incidentally, wasn't too difficult, once I actually sat down and decided to do it.) And upgrading from Tomcat 3.2.1 to 3.2.2b3 fixed that, once I'd found the bug reference in Apache's Bugzilla database for Tomcat (dated two months ago).

    For the moment, the performance has been adequate for our needs; having Apache as a front end for static images and such helps. I'll be interested to see what happens with that when the 3.3 and 4.0 Tomcat versions come out. If it becomes a real problem, we can always look at Jetty later, but, for now, I see no reason to change.

    One of my big goals for the community's new server was that it be "open source right down to the metal," and Tomcat is a big part of that.

    Eric
    --

  • I have hopes for Tomcat 4.0. But just because the 3.x series is shaky doesn't mean you should drop Java; there are a whole variety of servlet containers out there that should be able to run your servlets.

    I'm pretty pleased with Allaire [allaire.com]'s JRun [allaire.com]; I use it to serve an application that gets a half-million hits a day without problems. It's pretty zippy; on a single-processor PIII 800 MHz box we could serve two or three times the traffic we handle now. And they offer a free developer version, so it's well worth trying out if Tomcat doesn't meet your needs.
  • ...another victim of open source...

    Don't question the /. orthodoxy without a little elaboration, boss.

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

    Grammatical errors in original:
    1. The article says "deployment" whereas it means "deploy."
    That is all.
    Grammatical errors in your reply:
    1. What kind of English is that?: You mean "sort", not "kind". You are not referring to its formal classifications.
    2. I don't usually nitpick over grammar: It is incorrect to split your verb from its auxiliary by more words than "not".
    3. The idiom "to nitpick" properly takes "about", not "over" as its preposition. You mean "Usually, I don't nitpick about grammar".
    4. when there is stuff like that going on : "Stuff" doesn't "go on". If you were clear in your thinking you would not conclude that one error in the original is worth a rant on your part. If you did continue to believe it, however, you should write: "when there are mistakes of such a severity in the first paragraph alone".
    5. I have to wonder if the rest is worth reading. Whether, not if. Say: "I have to wonder whether the rest is worth reading."

    Hypocrite, take first the beam out of thine own eye, and then thou shalt see clearly to take out the mote that [is] in thy brother's eye.
    Humph.
    ~
  • if a weakly-typed, weakly-structured, multiple-inheritance language with a specialization in pattern matching and terse syntax is advantageous to a particular application, and there are plenty where this is so. mod_perl makes a quite passable platform for in-server processing and allows you to write your httpd.conf in perl for automatic maintenance, but the application bits and bobs aren't really there (except for Mason). Java's interfaces and reflection API allow Java modules to connect more safely yet more freely than in Perl.

    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

  • Good rant.

    While I fit into the category ...the myriad of clueless Slashdot posts from people who have never actually done anything more than a "hello world"..., the opinion I'm forming based on all of the "Mine Is More Gooder" posts is that, as with playing music, the quality of the final product has more to do with the musician than the instrument in question.

    Guess when I move to the web front-end of my project I'll rummage around the Linux distribution and see which of these groovy tools irritates the least. Or gaff them all off and do my own high speed, low drag unit in C++.

  • apache jserv is now more or less handled by the mod_jk [apache.org]. 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.

  • You compare JSP and perl, it is not correct. The correct comparison is:

    1) Java - Perl
    2) Servlets - mod_perl
    3) JSP - Mason

    I will not comment on (1) and (2), but Mason has some advantages over JSP. Just couple of features:
    - Mason components are real components, you can invoke them, passing the arguments, unlike awkward JSP include mechanism
    - Mason components have the init section, where you can put all the initialization stuff, and the args section, where you define all the arguments expected by the component and their default values
    - Page caching mechanism is superior to JSP

    I agree about the separation of business logic and presentation logic - it's very important, indeed. However, you are not getting it for free with Java/JSP. In either case, be it Java or Perl, it's responsibility of programmers and not the feature of framework (EJBs provide such a feature, but that's another issue).

  • Learn to read, my dear anonymous troll. I'm talking about JSP, not about Java classes or EJBs. JSPs are not components and they don't support the concept of JSP invocation/arguments. You can only include one JSP inside another JSP, that's all.

    BTW, the getInitParameter() is a very good example that shows the difference. Do you need to call getInitParameter (or whatever) from within your C or Java functions to get the arguments?

    JSP is a spec not a product, true. So what? Control over the cache parameters is not the part of that JSP spec. I can control the behaviour of cache using Mason function calls - for example, set cache expiration by time, by condition, by explicit action. In case of JSP, it's all controlled by the app server, and from my experience - current JSP sever implementations (I'm using Tomcat and IBM WebSphere at work) are less flexible than mod_perl/Mason combination.

  • Or you could try Roxen [roxen.com].
    It can be extended and scripted in many ways, INCLUDING servlets and JSP's. It has its own XML interpreter, can embed Perl, Pike (it's written in Pike, there have been articles on Pike here on /., look at the history), which is also OO. Roxen allows to define new XML tags in C, Pike, and XML, runs in a single process (with helper threads created as necessary and pooled for efficiency), has an extensive runtime library.
    PLUS it has bandwidth management capabilites (very fine-tuneable and extendable), can do on-the-fly graphics generation and blah blah blah.
    There's a (commercial) package for it that does extensive template-ization and presentation/application separation and kicks ass as a web content management solution.

    Just try it, it's only a download/compile away.
  • 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.
  • why would you architecturally want to invocate a JSP?

    Mason sees each page as a set of components. For example, header component, then a table, where each row is a table_row component, then footer component. Lets' say, to render each table_row, we need x, y, z arguments. So, in the appropriate point of the table template you put table_row(x,y,z). One should not wrap this thingy as a Java bean (or Perl module), beacuse it belongs to presentation layer, and it has some serious disadvantages to put any style- or presentation-related information in the Java (or Perl) code. Of course, this component approach is not specific to perl/Mason. We (or any other big site) are doing the same thing with JSP includes too, it's just not as clean and less convenient when working with a team of frontend/backend developers.

    Your remark about the number of independent vendors developing for Mason is correct and points to big Java/JSP advantage, indeed. Because of all the hype about Java, it's gained the critical mass and now we have all kinds of great App Servers, development tools, third-party components etc. A lot of good books, too. Also, it's much easier to find Java/servlet/JSP programmers than Perl/mod_perl/Mason programmers.

    BTW, all these factors are the reason we're currently porting a huge site from Perl/Mason to Java/EJB/JSP. I have somewhat mixed feelings about that. For small sites, I think mod_perl/Mason is a very good solution. But for big sites, Java/JSP is probably the way to go, mostly because of ease of language / teamwork organization / good development tools.

  • 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?
  • kewl thanks!!!
  • 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...
  • 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 [maden.org]
  • I fully agree, but don't think those shortcomings will have much effect on the future demand for Java geeks. Java is always considered, and often chosen, for new enterprise (i.e. server-side) development due to the happy convergence of:
    • Developers desiring to use (or have an excuse to learn) Java
    • Management becoming aware that they:
      • get a ~50% productivity improvement from their developers (compared to C++), and
      • won't be over a barrel with a single vendor ("gee, Sun, your price seems sorta steep; guess we'll buy IBM servers this time")
    Java experience isn't a drawback regardless of the job you're applying for; I got 3 offers recently for C++ gigs; they agreed that 3+ years as a Java developer would make me a better C++ coder.
  • 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.

  • Can't argue with you. Even though the demand for Java is going down, mainly because of the client-side realities, being proficient in Java is a good thing to see on a résumé for reasons beyond simply knowing the specific language.

    Cheers,

  • In The Problems with JSP [servlets.com], 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 [sourceforge.net] 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.

  • I've been using jserv for a while, but GNUJSP is a pain in the ass. So I wanted to upgrade to Tomcat which is supposed to be the natural option. What I found? A mess of configuration files (in XML format, many of them), bad organized packages and a replacement for make!!!!

    Once more time I find that java developers don't give a damn about the sistem they are running on, it a nightmare for administrators, but is the easy way for them.

    I really HATE java.
  • "a ~50% productivity improvement from their developers (compared to C++)," That's like saying shovels provide a "~50% productivity improvement compared to tableware or sharp sticks" in digging. Anything that only provides 50% productivity improvements over C++ is probably not worth getting into.
  • Dude, that's my whole point. None of the things I pointed out made any sense, and I purposefully left in some things in my reply that a grammarian could point to and say "could be better". it's a fucking joke :))
    ~
  • What other than Java has this kind of portability?

    Perl, Tcl, Python, Lisp/Scheme, Korn shell (only 1/2 kidding), ...
  • Cool.
    Need XML expertise? crism consulting [maden.org]
  • Then someone needs to tell Sun, because java has the same bug. Try putting all your constants in an interface, then recompile. You will find that .java files that use those constants do not recompile and will have the old values when run.
  • 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.
  • Ummm, isn't it sensible to load the class from the first place you find it in the classpath? The reason xalan worked great in other servers is that either a) they include xalan or b) they include nothing. Resin built in their own to support their XTP template language as an alternative to JSPs. Thanks would be more in order, my experience is that web-designers hate JSP.
  • Actually, resin's classes don't implement the interfaces I'm looking for, but they nonetheless prevent the correct classes from loading.
    I don't want to learn a new language to do XSLT transformations, I want to use what works everywhere. I design, write and deploy my own classes. I write my own JSPs, I don't need web designers (in my vanity site anyway), and the good ones love JSP it they are well done (have you heard about taglibs?), in my experience. YMMV, of course
    Nowadays most major servlet engines come with their own implementation of JAXP or what-have-you, and no one (but resin's) prevent xalan from working. You may have to explicitly tell what parser you want to use, which shouldn't be a problem anyway since it's not an uncommon thing to do. Try to do a search on google on xalan+resin and then tell me I should be grateful

    Victor

Slashdot Top Deals

Byte your tongue.

Close