Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Apache Books Media Software Book Reviews

Professional Apache Tomcat 136

Posted by timothy from the yowl dept.
Liam writes "Tomcat is a subproject of the Apache Software Foundation's Jakarta project, its purpose being to serve Java Servlets and JavaServer Pages. It's a complex piece of software and though the documentation is very comprehensive, it helps to have a good reference work to hand. There aren't many books on the subject to choose from, so a publisher could make a fast buck putting out an incomplete work lacking in depth. Fortunately Wrox Press has done a great job with its new publication Professional Apache Tomcat." Read on for the rest of Liam's review.
Professional Apache Tomcat
author Chanoch Wiggers et al
pages 600
publisher Wrox Press Ltd
rating 9
reviewer Liam
ISBN 1861007736
summary Comprehensive guide to Apache's Tomcat server

The book covers every aspect of installing and configuring Tomcat in a great deal of depth, detailing its every aspect. From standalone use (where Tomcat is used as a general web server as well as for serving Java content), to integration with the leading web servers Apache (both Unix and Windows versions) and Microsoft's Internet Information Services, nothing appears to have been left out (however, integration with Netscape's Enterprise Server is mentioned in passing early on, but doesn't appear again).

Being only a month old, it's pretty much bang up to date, covering Tomcat 3.x, 4.0.x and 4.1.x with Apache 1.3.x and 2.0.x and IIS 4 and 5.

The book starts with an introduction to the Apache project, and Tomcat's place in the wider scheme of things. The historical progression in serving dynamic web content from CGI to Servlets and JSP is charted, and there's an overview of JSP tags and general web application architecture. This is interesting enough and useful as background, but as this book is intended for administrators, it's covered quickly in the first two chapters, and the main business of installing Tomcat gets underway in chapter 3.

Installation is discussed with both Windows and Linux users in mind, from both binary and source distributions. As the Tomcat source is usually built with Ant, build and installation of this tool is also discussed (Ant and Log4j, both also part of Jakarta, get chapters of their own later in the book). From there, basic configuration of the standalone server followed by detailed examinations of the components that make up Tomcat's architecture fills the next 200 or so pages.

Serious users of Tomcat will wish to employ Tomcat with an existing web server, and four chapters concentrate on this job. There is more emphasis on Apache than IIS, though given Apache's dominance of the web server field, this is understandable. There is inevitably a certain amount of detail aimed at Apache and IIS configuration, and a basic knowledge of both is assumed throughout. However, any necessary information is included in detail; for example the (Apache) connector modules mod_webapp and mod_jk/jk2 are given a thorough treatment, describing their use from source installation to configuration, together with the pros and cons of the various connectors available. Beyond that, we learn how to design larger-scale setups, with an explanation of load balancing techniques and scaling of the system, and performance testing with JMeter, yet another Jakarta project component.

As ever, security is a major concern and gets a lot of emphasis. Before client authentication and the use of SSL are discussed, there's an overview of basic system security with Unix and Windows. This should be teaching granny to suck eggs for a book aimed at administrators, but it's only a few pages and completes the subject. More interesting are the sections on security realms and user/client authentication. We are presented with examples of authenticating against a MySQL database with JDBC (database connectivity with JDBC is a big enough subject in its own right, and so gets a separate chapter too), and digest authentication. We then move on to encryption with SSL: using Tomcat itself with the JSSE and PureTLS Java SSL implementations, then later with Apache and SSL (setting up mod_ssl with Apache gets a very useful appendix of its own, taken from Professional Apache 2.0, another Wrox book). Again, there's lots of detail, right down to how to get hold of signed certificates for your server. Here the book's general emphasis on Apache over IIS is most apparent, as SSL with IIS is not discussed at all. However, I have no experience with IIS, so I can't say for sure how serious this omission might be.

There's a very brief appendix on setting up Apache's Axis SOAP toolkit, but without any mention of SOAP appearing elsewhere in the book. As other concepts are introduced so well, it's a curious addition.

With nine co-authors (though only four got onto the cover photograph - I wonder if they drew straws?), one might expect wildly different styles throughout the book, but each chapter is consistently and clearly laid out with diagrams and relevant configuration file fragments where necessary. There's little levity and it's all written in a very business-like manner, but then this is hardly a subject you'd choose for holiday reading.

Professional Apache Tomcat is surely the definitive book on the subject. I recently used it to integrate Tomcat 4 with an existing Apache 2 installation, and everything went very smoothly. More than just a set of tutorials, it offers a thorough description of the whole architecture, and makes an excellent companion to either of Wrox's Professional Apache books.

There's no CD with the book, but Wrox's website provides some support code, and there are lively forums for readers at p2p.wrox.com.

You can purchase Professional Apache Tomcat from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Professional Apache Tomcat More

Professional Apache Tomcat

Comments Filter:
  • Tomcat's documentation is superior and it is so very simple to use. I don't think a book on the subject is really necessary. Perhaps if you are doing something extremely out-of-the-ordinary when you plug tomcat into JBoss, but it would be more of a JBoss issue than a tomcat issue.

    • Re:Book is really unneeded (Score:4, Insightful)

      by dubious9 ( 580994 ) on Tuesday November 19, 2002 @11:15AM (#4706965) Journal
      Yes, tomcat is simple enough to begin using for yourself, but this book aims at the industrial uses of it.

      Documentation mostly tells you what a system does. Books (wrox, oreilly) mostly tell you how to set up a system to do what you want it to do, and explain uses that you might not have thought of.

      I like and respect the writers for wrox, and they wouldn't write about it if they didn't think it was useful.

      If you are thinking about intergrating JSPs or applets into your already existing complex web architechure, then I would probably buy a book that has professtionals outline exactly what to do, and what best practices there are.
    • Okay Mister fancy pants. Try this one

      Where in the docs does it explain how to pass user_dir or ServletDir to Tomcat when it is integrated with Apache? I've seen writeups for the combersome process of setting up virtual servers for each user on a system but not much else.
    • It's very simple to use "as is". If you want to do SSL, client side certificates, or just understand the syntax of the workers2.properties file you are going to pass a lot of time searching with google.
      BTW, most of jk2 is not documented or poorly documented.
    • Actually, if you subscribe to the user mailing list I don't think you'd say this. I managed to get by with just the online documentation and google, but is seems like there are quite a few people who can't. Every day we get asked about Apache/Tomcat binding and help with various server.xml and web.xml problems.

      I never understand how some people can't use the resources available. Hell, the mailing list archive is online and people can't figure out that they should search there before asking the list. The list is running at about 50+ messages a day. Obviously someone needs this book.
    • > Tomcat's documentation is superior...

      I don't know which alternate universe you are living, but in my world, Tomcat's documentation is awful - in fact, my frustrations with the docs led me to buy this very book. Server.xml is a very complicated configuration document and web.xml can be, so this book is great to have a handy reference for that part alone. Unlike a lot of people, I don't consider HOWTOs to be all that useful. The scope tends to be extremely limited and they often don't bother to reference other documents that you are expected to be familiar with in order to follow the instructions.

      I agree with some posts on the lack of quality of Wrox books - but in this case, its definitely worth it. Good technical writing is worth its weight in gold. The only book I would prefer would be O'Reilly's Tomcat: The Definitive Guide [amazon.com], although according to Amazon.com, its not due out until March 2003.

    • It's also worth noting that JBoss isn't the only way to get EJB functionality with Tomcat, you can now plug OpenEJB [sf.net] into whatever Tomcat installation you already have setup.

      Personally, I like the ability to pick what Tomcat version I want to use. It's also nice to be able to upgrade when I want to upgrade and not have to wait for the next Jboss-Tomcat release to come out.

      Worth checking out.
    • I don't think a book on the subject is really necessary.

      A book is needed if one wants to get published and make money from book sales....
    • Ink cartdridges cost more than books these days.
  • A bit like "Advanced use of .htaccess" or "Windows Start Menu volume 1"?
  • Definitively Tomcat is THE SERVER, in servlet and jsp field. Maybe is slow in static content, but is the reference implementation.

  • The reason why i think twice before buying Wrox (Score:3, Funny)

    by the cobaltsixty ( 210695 ) on Tuesday November 19, 2002 @11:10AM (#4706923) Homepage Journal
    Every latest wrox book is a common recipe:
    - Take a red cover;
    - Fast time-to-market, by any means;
    - By any means, i mean: "-Oh, we need a book about Tomcat, sure... Hey, call India. How much chapters we need? Fifteen? Yeah right, ill pay each Indian R$ 10 per chapter... But i want fifteen authors involved".
    - Takes either the most handsome or the most weird, depending on their looks. Makes a professional quality-looking photo. Merge with the cover.

    Whats next? Shipments from New Delhi and Bombay?

    • Re:The reason why i think twice before buying Wrox (Score:4, Informative)

      by Neon Spiral Injector ( 21234 ) on Tuesday November 19, 2002 @11:40AM (#4707196)
      Yes, I'm glad someone else noticed this.

      I got the Professional Apache 2.0 book reviewed on /. also published by Wrox.

      I've read about 1/4 of the book. So far half of that has been on Apache 1.3. I can understand documenting differences between 1.3 and 2.0 in a 2.0 book. But don't go into depth on building and configuring 1.3. There are also numerous typos that are so obvious.

      It seems that this book was started as a 1.3 book, but 2.0 shipped so they tacked extra onto it and called it 2.0. Also to get to press first they only did a once over on the new information.

      I'll not buy another Wrox book.

    • I have a copy of Goodwill's Apache Jakarta-Tomcat next to me and it came out about six or seven months ago and, although it is a decent book, it appears to be a rush skim-over of Tomcat and not a thorough, in-depth reference work and not worth the $34.95 price (but, since it was the only one on the market IIRC, I had nothing to compare it with).

      Wrox's XML Schema book was one of the first Schema books on the market, but it was thorough.

    • Yes, it is a great pity that Wrox have started to go down this route...

      I remember the first Wrox book I purchased - "Professional Assembly Language" or something like that - this was back in '93 or '94, and was centered around '386 Asm, with a chunk of '486 stuffed in an appendix - The book was fantastic, for years, I would buy little but Wrox and O'Reilly, but Wrox have recently lost the professionalism which they used to have.

    • Why is that a reason to think twice? Fast time-to-market is good. Multiple authors working in parallel is one among several reasonable strategies to achieve it. The fact that many are Indian is completely irrelevant -- so what? Do you have some weird hangup where you only want to look at white anglo saxon males?

  • Tomcat is easy! (Score:5, Informative)

    by dougmc ( 70836 ) <dougmc+slashdot@frenzied.us> on Tuesday November 19, 2002 @11:12AM (#4706937) Homepage
    It's a complex piece of software and though the documentation is very comprehensive, it helps to have a good reference work to hand.
    Are you kidding? A sysadmin with some experience can successfully configure Tomcat without even really going through the documentation for the very first time in like an hour.

    Compared to Weblogic and especially Websphere, it's so incredibly simple it's silly. (Websphere especially is a *nightmare* to install and configure.)

    • Second that! It's like 3 lines in 2 xml files to get Tomcat going (granted the older versions were MUCH more difficult to set up). Setting up Websphere was like pulling barbed wire through my urethra.

      • Re:Tomcat is easy! (Score:2, Informative)

        by FortKnox ( 169099 )
        In Windows, its even easier. Install the installshield script, and place your jsps and servlets into the default directory. Voila.

        You can even get struts [apache.org] installed by plopping the struts jar file into the deploy directory, and it'll autodeploy struts instantly.

        • this explains your previous post as to the technical know-how to get it running - i suppose it took you the whole day to get a hold of mod_webapp.dll?

          unfortunately i consider the docs on the web and especially on the tomcat site woefully inadequate when you "have" to install the connectors from source onto a unix system. the modjk2 & webapp's quality is diminished by their docs. in the end i went with resin [caucho.com], which was a good deal easier (their documentation was accurate)

    • Re:Tomcat is easy! (Score:4, Insightful)

      by monkeyserver.com ( 311067 ) on Tuesday November 19, 2002 @11:23AM (#4707045) Homepage Journal
      That might be true, but there are countless companies that have NO sysadmin. You have, instead, an overworked project manager who has been forced to work on IIS w/ some piece of crap Servlet Container for the last umpteen years. Now that he's convinced management to let him run linux and tomcat w/ apache he has very little time to set it up, and not a ton of experience. He would benifit greatly from this.

      And don't, for a second, believe that most ppl know as much as your average slashdot posting geek. This book can be very helpful to those who would like a little hand holding. It also might give even you some insight into things you haven't done or haven't even thought of...
      • That might be true, but there are countless companies that have NO sysadmin. You have, instead, an overworked project manager who has been forced to work on IIS w/ some piece of crap Servlet Container for the last umpteen years. Now that he's convinced management to let him run linux and tomcat w/ apache he has very little time to set it up, and not a ton of experience.

        He's not a sysadmin, but knows enough to convince management to let him run linux and tomcat and apache.

        Is management that gullible that they can be hoodwinked by someone who isn't a sysadmin, but wants to ride on the linux train?

        • Re:Tomcat is easy! (Score:2, Insightful)

          by seanb ( 27295 )
          Tomcat doesn't require (or imply) linux. It works well under Windows, OS X, or anything with a viable J2SE runtime.
          • that is correct, however, I was just making an example, not making any statement about the platform tomcat runs on. I have run it for quite some time on both windows and linux.

            But thanks for pointing out something that may have been inferred by many readers.

    • Re:Tomcat is easy! (Score:5, Insightful)

      by deppe ( 27130 ) on Tuesday November 19, 2002 @12:07PM (#4707427)
      For the casual developer or admin, I think the new Sun-endorsed XML formats for webtrees and other configuration data is worthless. It's simply too verbose for me.

      I recently played with Cocoon (which is a lovely publishing framework) but finally gave up with writing my own "mini-framework" with it because of the awkward XML configuration files.

      Don't get me wrong, I love XML for what it is good at, data exchange and such applications, but the idea that _everything_ has to be in XML isn't a useful one (IMHO).
      • It's simply too verbose for me.

        The problems developers face these days regarding configuration files... I was also against using XML for something like config files (I come from a world of crontab and smb.conf), but eversince I started using Tomcat alot with their XML config files I started figuring out why they use it.

        Basically, XML allows alot of verbosity in the XML file, and XML parsers are a dime a dozen (or less), and when I code some silly thing I want it to be highly configurable and I don't want to code Yet Another Config Parser.

        XML allows alot of structure to be easily realized in a human-readable format that is easy to parse.

    • It could be easier to unpack and run, and still be lacking in documentation or when you have to tweak the setup.
      BTW, weblogic and websphere are full transactional EJB containers and Web containers. Tomcat is just a Web container (JSP/Serlvet). Let's not compare apples and oranges.

    • Re:Tomcat is easy! (Score:3, Informative)

      by Black Perl ( 12686 )
      Compared to Weblogic and especially Websphere, it's so incredibly simple it's silly. (Websphere especially is a *nightmare* to install and configure.)

      If all you need is a servlet container, you shouldn't even consider Weblogic or Websphere--overkill. You would have been better off using JRun as a comparison point, although the latest versions of JRun bring it closer to the J2EE servers than Tomcat.
      • YM "resin". HTH.

        I haven't used JRun since discovering Resin about three years ago, but the advantages Resin had over it were:

        • Faster than a greased snail sliding over frozen snot.
        • Source available. (not open source)
        • Very quick bug resolution. (Having source available made it possible to supply very precise bug descriptions, also.)
        • Free for dev use, charging only for commercial deployments.
    • I've had real problems with tomcat under debian several times. One one machine, I couldn't get it working from apckage after lots of attempts. So I downloaded the source and installed it. I've had to patch it with the recentish security hole. Now I can't get jsp pages working. "org.apache.jasper.JasperException".

      On my machine at work, I spent all of last friday trying to get tomcat working again after an apt-get upgrade. No luck. There's some jspo library it justkeeps complaining about (even though I'm not even using jsp with the server and have nuked all the example stuff). Tried uninstalling, reinstalling. No luck. Tried nuking all configuration and copying of a colleagues computer who's works. No luck. Had colleague and sysadmin scratch heads with me for a couple of hours. No luck.

      Tomcat's a bitch.
    • A sysadmin with some experience can successfully configure Tomcat without even really going through the documentation for the very first time in like an hour.

      I sure wish this were the case, but successfully getting Tomcat to work is non-trivial for those of us who haven't figured out the "Java way of doing things"! We've spent 40 man-hours this past weekend trying to get samples from any of several books (not the one in this review; it wasn't available on short notice) to run... and we have to do that before we start implementing the project we're being paid to do!

      We've run in to numerous bits of "assumed knowledge" on this project. It is assumed that, if you're working in Java, you already know where this or that piece belongs, and why it is to be there. It is assumed that the install will cover all the background information, like setting up CLASSPATH, CATALINA_HOME (or is it TOMCAT_HOME? The books and documentation disagree!), JAVA_HOME, etc.

      Guess what? The Sun Linux SDK install didn't set JAVA_HOME, so the Tomcat install didn't know where to look, so it got it wrong. We installed J2SE 1.4.1, and that may be why none of the book samples won't work... but, we haven't been able to tell, because the error messages are either non-existant, or so verbose as to be nearly meaningless and difficult to track, unless you KNOW what they mean before you start... part of that ASSUMED KNOWLEDGE.

      Is the WROX book a good thing or an evil thing? Heck, I don't know, haven't seen it yet. But, I think it is silly to dismiss the need books, just because some people already have the ASSUMED KNOWLEDGE to figure out the Tomcat documentation!

  • great book. (Score:4, Informative)

    by Anonymous Coward on Tuesday November 19, 2002 @11:14AM (#4706958)
    I am a professor at a large technical college. I use Tomcat in my Distributed Java class and I have to say this is one of the finest books on Tomcat I have seen. I have recommended this book to all of my students.

    The book is well-laid out (moreso than most of the GNU/Hippy students!). It offers a good overview of all of the major pieces of functionality in Tomcat and does a particularly good job of describing the different manners which you can integrate Tomcat and Apache.

    My only complaint might be that the section on Axis was extremly light-weight. I would have loved to see more detail in this chapter, even though the information in the chapter was a good starter.
    • How come I see so many - "This is a great book, buy it!" posts by Anonymous Coward in here. If Mr. - sorry - "Professor" Coward is willing to testify, why do it anonymously?

      I have no opinion on whether this is a good book or not, but I get the feeling that the authors/publishers are hyping this book. Which makes me think that it won't be purchased on its own merits, which means that this book is a piece of crap.

      But that's just my outlook. Please feel free to form your own opinion.

    • Re:great book. (Score:2, Interesting)

      by AndyDeck ( 29830 )
      >> I am a professor at a large technical college....

      Hello, mr. anonymous coward. I certainly hope that you are actually John Carnell, as your comment is cut&pasted from his Oct 31 review of this book on Amazon.com. If not, this message is a copyright violation.
      • Actually somebody did plagariaze my comments off of Amazon.com. I am not very happy about it, but I doubt I have any real recourse :,>.

        A couple of things though:

        1. I do teach Java programming at a large technical college (Waukesha County Technical College, largest in the state of Wisconsin). I teach an intermediate Java programming class that has a heavy emphasis on servlet and JSP programming.

        2. I do think the book is well-written and here is why. Many of the people on Slashdot are usually well-rounded developers whose abilities and experience are often greater then the average developer. Tomcat does have excellent documentation, but many people do not translate what they see in a a browser as well as what they read in a book. I think the Apache Tomcat book provides a great introduction to Tomcat as well being a useful reference manual. I have prepared material in my class based off of this book and have found it easy to follow and useful.

        3. A note of disclosure: I have written for Wrox in the past (4 books) and done some technical reviewing work for Wrox. I have NEVER participated in any kind of technical reviewing for the Apache Tomcat book. Wrox sent me a copy of the book by mistake (I was suppose to be getting a couple of copies of my own book :,()). Even though I received this book by mistake I found this book incredibly useful because it provided an easy to use reference manual that I could recommend to my students for purchase.

        Wrox has never asked me to "shill" for this book (or any other book) on Slashdot or Amazon.

        I made my review on Amazon because I liked the book and I think that it is worth picking up.

        I am posting here today because a colleague of mine sent me email telling me someone plagiarized my review on this site. The review posted here is pretty much my words (except for the hippy part :,()). I stand by my review on Amazon.

        Sincerely,
        John Carnell

  • Tomcat docs are good, but always need improvement (Score:4, Interesting)

    by f00zbll ( 526151 ) on Tuesday November 19, 2002 @11:29AM (#4707092)
    Having used Tomcat quite a bit, some things aren't as easy as they should be. Doing a simple stand alone installation takes only a few minutes on a clean system, but frequently the system has weird configurations. There are certain things Tomcat documentation could use improvement, so the book is a nice addition. Often I find documentation is written for those with experience and isn't written in plain english for newbies. Looking at the number of posts on tomcat-user mailing list, more than half the questions are due to user error and documentation. More documentation is always a good thing. well most of the time.
    • I second this!

      They need improving a lot. Everything is in there but it is not clearly laid out. The logic is often wrong.

      My HOWTO integrate Tomcat/postgresql/Dreamweaver Ultradev was an attempt at helping the lower end of application programmers like myself to get a quick start. The latest MX version [tgds.net] points to a HOWTO at Sun for Tomcat setup. It is much easier to follow than the docs.

  • Nice to see (Score:4, Informative)

    by Kandel ( 624601 ) on Tuesday November 19, 2002 @11:33AM (#4707132) Journal
    Just remember "Professional Apache Tomcat" is aimed purely at Sys-admins, not programmers. Programmers will learn everything they need to know about configuring Tomcat from the de-facto standard text of "Java Servlet Programming 2nd Edition" [oreilly.com], which every Servlet programmer will or should have in their reference collection. The documentation of Tomcat is good, but for Sys-admins, being able to just flick to a page and copy down an example is much quicker and easier than hunting around the online documentation. Not to mention the benefits of printed text over online text...especially if your notebook battery runs out when your trying to have a read in a secluded place. Tomcat is a complicated application, and the need for a good printed text is much needed. A lot of functionality of Tomcat can be long and tedious to setup (e.g. Authentication), and it's great to see a text addressing these issues.

    All in all, good work Wrox!

    • Its nice to see either a.) An author of the book or b.) a wrox employee create a /. user to make post about this book.

      ...is aimed purely at Sys-admins, not programmers. Programmers will learn everything they need to know about configuring Tomcat...

      OK, so we have a system that needs tomcat, complete with sysadmins and java developers. Why would you let the sysadmins configure tomcat, when you have developers to do it?

      Ok, if you already have a product, the developers were consultants that already left, and the sysadmin is switching to tomcat, peruse the tomcat website, cause the doc is extremely easy to read and simple to understand.

      Honestly, any sysadmin worth his salt should be able to understand how to configure tomcat in under an hour, and not need any book when the online doc is sufficient.

      Besides, tomcat is mainly used for prototyping pages and making small internal sites. Anything larger goes into a full scale J2EE server like JBoss, Weblogic, or WebSphere. Any other type of tomcat site is a small majority that isn't enough for wrox to make money off this book, and is specialized enough to contact the tomcat mailing list and get your answers from the developers.
      • I think you underestimate the proprotion of production websites that do not use the EJB portion of J2EE.

        A web app based on Servlets or JSP but not EJB can handle plenty of traffic.
        And you avoid the large architecture, large programming staff and long schedules of J2EE
        based web apps.
        Not everyone is a yahoo or an amazon.

        Also, the J2EE environments are much harder to configure.
        Unless you have a crew of developers with lots of J2EE experience on your platform,
        you are going to have developers trying to figure
        out why there EJB code doesn't work
        instead of implementing business logic.Your mileage may vary, but I have yet to hear of
        a J2EE environment that was easy to configure
        and didn't fight you every step of the way.

        Tomcat is a breath of fresh air by comparison.
        • Its all about businesses and how they work.
          Primarily, when they choose a webapp server, they are looking for reliability, maintainability, and (here's the big one) support.
          Price is on the lower end of the chart, withp olitics, like partnerships with IBM/BEA, being well above 'price'.

          Now, you have tomcat and apache. Very reliable, easy to maintain, no support (unless you have an inhouse expert).
          You have the commercial product (I'll use Weblogic) that is just as reliable, a little more difficult to configure but easy to maintain, full support (and more efficient of a server, for companies with high bandwidth sites). Oh, btw, the commercial product costs about ten grand more.

          The company then forks over the ten grand. Why? Mostly for the support. Open Source has a great advantage of price, but a HUGE disadvantage of support. It'd be nice to see a national-wide company that does nothing more but install, configure, maintain, and support open source products.
          • Unfortunately, my experience with the commercial J2EE product was from within the company that owned and sold the product.

            So even though there was "support", we couldn't get it (the cobler's children has no shoes).
            We could not use one of the more popular commercial J2EE environments, because they were a competitor.

            We would not have needed to get support for Tomcat because we could figure it out for ourselves.
            Internal politics, however, made it very difficult to build a web app without EJBs.

            Other projects that started earlier were finding that they had performance problems with our J2EE plaform and they had to
            use bigger hardware than what was planned.

            A project that implemented using Servlet technology and got into production before J2EE became the "one true way" is stable in production under Tomcat.
            It is in use world wide.
            Of course, your mileage may vary. Your choice of J2EE platform may have better support and work better than the one we used.

    • Re:Nice to see (Score:4, Insightful)

      by GOD_ALMIGHTY ( 17678 ) <(curt.johnson) (at) (gmail.com)> on Tuesday November 19, 2002 @11:53AM (#4707296) Homepage
      I don't think any of the generic Servlet/JSP books are much more helpful than explaining the spec's from Sun. They introduce basic patterns and such, but don't do much to help with taking advantage of the architecture while maintaining portability. Tomcat 4.1.x has caching features that will break 'loosely' written code that would work using Jasper on Jetty. The spec doesn't say you can't do these things, but developers need better guidence on what to keep in mind while writing code that needs to be portable, versus just writing for a specific container.

      My experience has been that Tomcat does things the 'right way' where others gloss over ambiguities in the spec. Having a detailed explination, with examples on how to write code 'the right way' so that Tomcat will be happy, makes the job of porting to other containers easier.

      The 4.1.x stuff seems to be a refactoring of previous versions that continues to enforce best practices to insure data integrity and scalability. The problem is, I need to be able to figure this out without having to read through the source. I don't mind it when I run up against issues and need to understand what's happening internally (I've read a ton of the jakarta-commons and struts taglib source), but to have a 'developer's guide' that does more than cover the basics of JSP/servlet development would be very helpful.
    • especially if your notebook battery runs out when your trying to have a read in a secluded place.

      If your bathroom breaks are so long that your notebook battery runs out, maybe you should eat more fiber.

  • Tomcat works very well in my opinion (Score:5, Informative)

    by municio ( 465355 ) on Tuesday November 19, 2002 @11:34AM (#4707138)
    We have been using Tomcat for almost 3 years now and we haven't had any unscheduled downtime yet.

    We first started to use it as a development platform. The idea was, "let's develop a Servlet/JSP based application and we will choose later the production server". We wanted to test the application/web servers on our specific application. We though we will end up buying some commercial application. But when the time came to go to production Tomcat had proved itself. It was more than good enough.

    We know we can get some extra performance by switching to other web servers, but we don't really need to, Tomcat is more than fast enough. Considering in the global performance of the application, the impact of Tomcat is minimal, as opposed to the database or the LDAP. Our time is better spend improving the database side of the app. Besides Tomcat is very easy to use the source code is very easy to read (as opposed to other open source projects).

    At this point, if we switch platform it will be to base our application on JBoss (maybe hooking Tomcat to it). We are not yet convinced that EJBs will benefit our application, but we are seriously considering using JMS.
    • You don't need to switch platforms to use EJB's from Tomcat, and you don't have to embed Tomcat into another EJB server either. The OpenEJB project (openejb.sf.net [sf.net]) has just released support for embedding OpenEJB into Tomcat. Yes, that's right, now you can plug EJB functionality into your existing Tomcat installation, not the other way around. No need to port all your webapps over to an EJB server with Tomcat in it, no mucking with Tomcat's config files, no hacking the catalina.bat, ...no need to mess with your Tomcat setup at all.

      They have this little war file you copy into your webapps directory and that will load in all the EJBs and everything else for you. If you don't want EJB's anymore, just delete that war file.

      They released a preview of the integration on their user list several weeks back, we've been using that for a while now. The official release came today. Was pretty easy to upgrade, just had to replace the old war with the new war and restart Tomcat.

      Works well so far.

  • Tomcat and linux reduces dev cost & time (Score:4, Interesting)

    by Anonymous Coward on Tuesday November 19, 2002 @11:37AM (#4707162)
    We are building our application in Java with Netbeans and deploying our apps in Tomcat and Linux. Our dev cost is very low or is 10% to .Net workshop. Our site is internal and it has very few issues and the apps are very stable and can take a lot of beating. We are looking at TogetherJ for our IDE to do some modelling for our future projects

    I think Java and Linux is the future

    We see that more and more
    • Our dev cost is very low or is 10% to .Net workshop.

      whooo there... take it easy on the FUD will ya?.. generally, the bulk of development cost is labor hours, not the tools. the tools help to reduce the labor hours. Sure java and linux may be the future, but.. microsoft software isn't that much cheaper to develop than java/open source software. the biggest development costs are in the hours spent doing analysis, designing, building, and testing. your 800$ pc with 3000$ of software on it is chump change in comparison to the 6 man months put into the project. also, considering the biggest risk in a project (what can fsck it up), is also those 6 man months.

      oh wait, you said internal project. sorry. didn't catch that. most companies are ok using MS Access for internal projects. you'll be hard pressed to find anyone willing to invest a dime on software tools for an internal project. and if full time people are assigned work to an interenal project in this day and age, i would be slightly curious when the pink slip might come my way.
  • Picked up that one yesterday. I bought it cause Rick Hightower (Java Tools for Extreme Programming) wrote the chapter on struts and ant/xdoclet. I haven't been able to go through the whole thing yet, but I need good reference info and insight into how the new Jasper2 engine handles caching of tag libs and some of the quirks that come up in JSP/Servlet development WRT insuring clean separation of data in the various scopes. I'm also very interested in seeing how struts and the JSTL should behave in the container.

    I don't think this info is very well covered in the Tomcat docs, dealing with Tomcat development is not the same as the '.htaccess' file as one poster suggested. If your trying to work out why the other guy's JSP/custom taglib stuff isn't as portable as it should be between containers, you really need this type of info.

    I'm dissapointed the reviewer sort of glossed over this book, he mentioned the architectural info in the last paragraph, and highlighted all the crap that's already talked about in the Tomcat docs.

    I already read most of the open source J2EE/dev mailing lists and visit numerous authors blogs. Trying to tie all this stuff together, while figuring out where it's all headed and discerning the best practices is a bit of a daunting task. The differences between the Jasper and Jasper2 engines is a lot of info, combine with the state of Jakarta-Commons, the rise of Jelly and Maven, and AOP + XRAI coming down the pipe in XDoclet2 and you've got a lot of material to pour through that isn't well documented yet. (ok that's a little out of scope for these 2 books)

    I need good books that really help me to formulate development methodologies that scale up and promote efficiency when doing full J2EE app development.

    So does anyone have any reading recommendations that will help sort all this out? Should I get this book too, or stick with Mastering Tomcat Development?
  • The problem is I'm using JServ (an early precursor to Tomcat that handles servlets.) Having JServ installed seems to prevent Tomcat from installing itself properly. Does anybody have any links that show how to migrate from JServ to Tomcat?

    Specifically, an overview of the JServ unistall, Tomcat install on RedHat Linux, and a document that describes config file changes that will be needed.

    • I believe Tomcat can be used as a drop in replacement for JServ (so, the requests that would have gone to JServ would now go to Tomcat). You could try Catalina (Tomcat 4.0) and start it up to listen to the port JServ was listening to.

      The documentation talks about how to set up Tomcat as an adapter. I wish I had more specific info. However, I am pretty sure that the steps are straight-forward.

      S
    • Been there, my friend!

      The biggest problem in migrating from JServ to Tomcat is that the two products, while similar in what they do, are very different in implementation. JServ had one bulk directory for all of it's servlets (insecure! insecure!), and did not support JSP very easily (IMHO). Tomcat, based on a later servlet specification than JServ, introduces the concept of a 'webapp', one or more descrete containers that allow for better security. I would say the concept of webapps is crucial to understanding the differences between JServ and Tomcat.

      As far as installing Tomcat - how are you receiving the distribution? RPM? TGZ? I have only worked with the tgz archives, not the RPMs, but here's what I did:

      My JServ installation was in /usr/local/jserv, so I extracted tomcat to /usr/local/tomcat. Since jserv and Tomcat both bind to the same ports (8080 for http, 8007 for Ajp12 - and then tomcat adds 8009 for Ajp13), so you can't run both at the same time without reconfiguring all these ports (which has it's own set of problems if you're trying to integrate with Apache). So, the best solution is to first stop JServ, and then stop Tomcat.

      If you want to have all your old servlets work like they used to, take them from the JServ's servlet folder, and copy them to $TOMCAT_HOME/webapps/ROOT/WEB-INF/classes/ - be careful doing this, that you don't overwrite any sample files that ship with Tomcat that you may want to look at in the future. There is no guarentee that they will instantly work - there are some changes in the Servlet spec in Tomcat vs. JServ, so if something doesn't run, look at your error messages, etc, etc. But from my experience, it worked pretty well.

      Using a 'webapp' container is so much easier once you get used to it - libraries can be self-contained in your app, if you have virtual hosts, you can allow some webapps on host, and other webapps for another. And be sure to check out about setting Context parameters in the WEB-INF/web.xml file - much, much easier (and more robust) that having to set init parameters for each individual servlet!

      Good Luck!
      • Damn! Why didn't I preview!

        4th paragraph, last sentance: I said "first stop JServ, and then stop Tomcat". Hopefully the error is apparent to all, but just in case, I meant to say "... then START Tomcat".
  • If so, then maybe I need to get you in touch
    with our sys-admins.

    we (they) have had a horrid time getting Tomcat
    stable on development servers. Something about
    not releasing memory or something.

    • Re:Are you using Tomcat on Solaris 8? (Score:4, Insightful)

      by j3110 ( 193209 ) <samterrell@gmail ... m minus language> on Tuesday November 19, 2002 @12:08PM (#4707443) Homepage
      Try a different JVM if at all possible.. If not, you can configure the JVM to compile useing jikes. The problem you probably have is that the toy compiler that comes with the JDK that's written partially in java, turns out to leek memory (just enough to be annoying if you have a lot of JSPs). There are how-to's online for setting up jikes and tomcat. This issue has been known for a while, but SUN nor Tomcat feel like it's a big enough issue to get upset about. You could also have a look at Jetty which is faster than Tomcat and more stable and yet easier to set up.
    • yes I've been using Tomcat on Sol 8 for a while now.
      Works fine once you've broke the back of it but
      I agree that it's a real bitch to start off.
      Those who use it on a Linux platform have it easy as
      it works straight out the packet. With Solaris
      you need to put the brain in gear.
      By the way I'm free for consultancy at any time!!!
      http://www.apex.is.co.uk
    • For tomcat to do this would require a bug that would show up on all platforms (ie maintaining strong refs to unneeded objects). Perhaps it is the Solaris VM? Hmmm, I doubt it... Perhaps it is your developers ;-)
  • I have not been impressed with Wrox books in the past. Too many of them have so many authors that the book's focus is poor. Even one Wrox book I have with two authors has examples so mired in their own utility library that I lost track of what the example were trying to accomplish and how. Plus about 1/4th of the book was incomplete reprints of Javadocs and specs that I can get over net (why enclose CDs any longer?).

    That said, I will definately check this book out. We use Tomcat a great deal (with Apache and IIS) and the more info, the better.

  • review license infringement? (Score:5, Interesting)

    by larry bagina ( 561269 ) on Tuesday November 19, 2002 @12:05PM (#4707403) Journal
    Liam (the reviewer) also posted his review on amazon.com [amazon.com]


    Now, aside from the irony of the slashdot review pimping the book for barnes & noble [bn.com], under the Amazon.com terms of service, all reviews become exclusive property of Amazon.com.


    Like it or not, this is just as serious of a licensing breach as if Microsoft Word included emacs code.

    • if Microsoft Word included emacs code. ?????

      Now that explains why Word is such a pig!

    • Re:review license infringement? Sorry-bullshit (Score:5, Informative)

      by Software ( 179033 ) on Tuesday November 19, 2002 @02:04PM (#4708819) Journal
      This is pure bullshit. If you read the Amazon TOS [amazon.com], you would see this part,
      If you do post content or submit material, and unless we indicate otherwise, you grant Amazon.com and its affiliates a nonexclusive, royalty-free, perpetual, irrevocable, and fully sublicensable right to use, reproduce, modify, adapt, publish, translate, create derivative works from, distribute, and display such content throughout the world in any media.
      Nowhere in here does it say that "all reviews become the exclusive property of Amazon." All this item, and the rest of the TOS, says is that Amazon can publish the review, and that you have the right to grant Amazon the right. This is perfectly fair, IMHO. If you're submitting a review to Amazon, OF COURSE they should have the right to publish it - why else would you submit it.

  • Tomcat Speed (Score:2, Insightful)

    by markv242 ( 622209 )
    Does the book have a chapter on optimizing Tomcat's threads to provide better performance than the out-of-the-box installation? If not, then don't bother buying the book.

    Instead, use the money to license a copy of Resin [caucho.com] which is, for lack of a better description, Tomcat on Nitro. It follows the reference implementation of JSP and Servlets just as well as Tomcat does, and even the default configuration, which is tuned for development, outperforms Tomcat.

    The configuration of Resin is almost exactly like the config of Tomcat, so I honestly don't see why you'd pick Tomcat over Resin (unless you were having trouble getting the 1.2 or 1.3 JDK installed on your FreeBSD box, something that is historically difficult to do).

    • First let me say that I use Resin for our production systems and LOVE it. But you seem to be missing the point that Tomcat is FREE. Resin is only free if you do NOT use it to make money. Granted Resin is cheap (under 1k), but not free.

      Also I would say that getting Resin hooked in to Apache 1.3.x and configured is far easier than Tomcat 3.x. I know 4.x is out, but I haven't had a chance to play with it.

      I believe another difference is that Resin will support some J2EE stuff out and Tomcat won't. Not that I use CMP beans and stuff, but a version of Resin does support it.

      I kinda would like a good book on JBOSS and Apache. Does anyone know if JBOSS has an easy way to deploy your EJB's yet, or do you have to write XML code?

  • Shameless Plug (Score:3, Interesting)

    by CmdrWass ( 570427 ) on Tuesday November 19, 2002 @12:31PM (#4707720) Homepage Journal
    A while back, I wrote and published a straightforward how-to for integrating Jakarta into Apache (getting Jakarta to share port 80 with Apache as opposed to using 8080).

    So... if anyone is interested:

    http://wass.homelinux.net/howtos/Jakarta_How-To.sh tml [homelinux.net]
  • I've been looking for more information regarding Tomcat. The docs which come with the product don't provide all the information I need. Also their web site is basically a mirror of the docs in the product.

    Any direction would be appreciated.

  • those covers (Score:5, Funny)

    by avandesande ( 143899 ) on Tuesday November 19, 2002 @01:21PM (#4708324) Journal
    I know someone that covers their wrox books so they don't see the glazed stares of the authors. I just scratch their eyes out with a pocketknife. The covers of my Oreilly books never weird me out....
  • My favorite quote in the review:

    "This should be teaching granny to suck eggs for a book aimed at administrators, but it's only a few pages and completes the subject."

  • Comments from someone who used it found it a lifesaver.

    I spent days (well hours... but felt like days) trying to figure out what Web Server connector (JK/JK2/WARP) to use to tie Tomcat to Apache, and why and how to get it all to work. This book saved me a lot of effort- I did go over the Tomcat user docs, but they were not very helpful.

  • Wrox Press has done a great job

    Although Wrox has some good books, their best IMHO being Michael Kay's XSLT book, they are well know (at least around these parts) for egregious spelling, factual, and gramatical errors/mistakes.

    My general strategy is that if OReilly or Addison Wesley offer a book, buy that. Only If their text is not available and if the Wrox text is on sale will I think about purchasing the Wrox version.

  • after I paid AUS$110 for a book titled something like 'Professional Microsoft Transaction Server'. It was the worst book I ever paid money for. I had a look at their other books and realised how they cheat. Since then I stick to Adison Wesley and O'Reilly mostly.

Slashdot Top Deals

The sooner all the animals are extinct, the sooner we'll find their money. - Ed Bluestone

Close