tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike DiChiappari <>
Subject Re: I don¥t understand the objective of this open list !
Date Tue, 10 Dec 2002 02:43:03 GMT

Thank you for your candid response.  I believe I understand the point 
of Jakarta now.

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

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.

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

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.

>Currently, I run Tomcat 4.12 and Apache 2.043 on a
>Windows/2000 Pro development box with multiple virtual

That's one of you (and I'm assuming you're a developer of tomcat)./

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

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.

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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message