Thank you for your candid response. I believe I understand the point of Jakarta now.
Since you say "we're" I assume you have had your hand in tomcat development. If this is so, then I believe it is true that in order to be able to successfully use tomcat, one must be involved in it. I am glad that is not true about other things in life. For example, I can drive a car, but can't (and have no desire to) build or fix one.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.
I understand J2EE methodology, design standards, how to design, build, develop and code in Java. I can figure out how to setup Weblogic, iPlanet, and JRun. I guess I still am not savy enough to use tomcat.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.
That's one of you (and I'm assuming you're a developer of tomcat)./
First of all, this thread was started by someone who could get no support and was complaining. I'll leave it up to you to go through the mail archive to find the original poster (how do you like being referred to the mail archives). At least with a vendor I have someone to yell at. And I've seen that technique work.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.
Secondly, I am not so full of myself to take responsibility for an entire app server. Yes, it is worth it to pay a few bucks to a company - just for the accountability. When your medical software can not meet FDA guidelines or you get sued because of a bug in your app server - good luck. I feel like I can depend on my app server vendor more than whoever is Jakarta.
Third, I'm not worried about my J2EE vendor going out of business. The entire point of J2EE is that it is a portable platform. I've already ported between real J2EE app servers with little trouble.
Fourth, I've had success with much of the open source and Linux software. We run Redhat with sendmail, Apache with PHP (Horde and IMP), and have built solutions with Xerces/Xalan. My main complaint is with Jakarta/tomcat. It really is awful.
Even though I disagree with you on just about every point, I am going to take your invitation. Bye bye tomcat.
Mike
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
