Mike, We're happy not to have you use the software. If you read the documentation for other application servers, you'll quickly find that there is an equal amount of 'geek' speak.
Sad to say, but at some point you need to understand the technology and know what you are doing in order to accomplish a reasonably complex configuration. Currently, I run Tomcat 4.12 and Apache 2.043 on a Windows/2000 Pro development box with multiple virtual hosts. This poor beleagured box also supports mod_perl, mod_php, cocoon (2.1 - reasonably late CVS release), Xindice (1.1 - reasonably late CVS release), jetspeed (reasonably late CVS release), postgresql, mysql, cvs server, soon to have ColdFusion, and a partridge in a pear tree (sorry - obligatory seasonal greating). I also switch occaisionally to IIS 5.0 (mostly to torture myself - but also to check interoperability). I will run the same mixture on Solaris and Linux (sans IIS 5.0) when the machines arrive. We've covered the ground, have demonstrated where the documentation is, have provided several commercial books for the software, and pointers to resources available on the Internet. What there isn't for the Apache products is a company to rant and rave at. In a way that's a good thing, since it frees the developers to do what they do best - develop leading edge software. Us user types get the fruit of that development effort at a cost - we have to learn about the technology. If we find the technology particularly useful, then we contribute back to the effort. Some of us write bug fixes, others of us write documentation, and others of us answer what we can on the mailing list. Complaining about what isn't is in general not in anyone's best interest. Rather than complain, do. If you don't wish to do, then don't complain. I understand it if your management has asked you to perform some application build on Tomcat, and your experience has only been with vendor hand-holding. It's time to start learning the basics, and not vendor-speak. This I think is the major cause of IT issues today. People implement vendor solutions without understanding the underlying technology used to meet the business requirements. This leads to people being familiar with vendor implementations, and not the underlying standards. What happens when a vendor goes out of business? What happens when the vendor decides not to support your favorite feature? What happens when the vendor decides not to implement your desired feature. Sure they may lose your business, but it's hardly the only business that they have. However, what you've lost is all the investment in vendor technology, since you've not invested in the fundamentals underlying that technology. In short, you either change your business practices to suit the technology that past [bad] decisions have constrained you to, or you throw away a lot of investment. Or, you take the third road, which is learn what you're doing with the technology, how it works, and why [the business reasons] you're doing it. Short answer - grab the rope and pull, or go find another effort. /mde/ just my two cents . . . . __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
