tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Villar <>
Subject Re: Why tomcat 4 or even 3?
Date Thu, 16 Sep 2004 13:03:10 GMT
That's true yoav, actually i live off that kind of things, however, what 
really amazes me is the messages that arrive at this list saying "i've 
just installed 4.1.x"..... the scenario you explained of replication a 
production environment on test grounds is a good approach, but i don't 
think everyone out there is deploying a test environment when installing 
the 4 branch. My principal concern about this topic is this: if the 
tomcat community fosters the use of old branches, people will start to 
get old bugs, old problems and will receive the tired response in this 
list "search this .... it comes up a lot", and that goes in detriment of 
the whole Tomcat community image (a mighty and solid image) and you will 
hear from some jerk things like "yeah, i tried tomcat, but its rather 
buggy and slow, i prefer the ClosedSource_VENDOR_X solution". The 
problem here is that management departments worldwide are concerned 
about the ROIs and TCOs of the systems, and we must give them those 
digits, just to grasp more "market share" (yuck!! management lingo, i'm 
sick of it, hate it or love it, we must live with it), revealing 
security and maintainability issues of having installed some old tomcat 
branch. Those are my toughts about this matter.

John Villar
Gerente de Proyectos
Computadores Flor Hard Soft 2058 C.A.

Shapira, Yoav escribió:

>All the arguments mentioned by others in this thread, especially the
>"why upgrade if it's working" one, are raised frequently by companies
>and developers.  It's a matter of resource constraints, as is everything
>else in life ;)  Even you abide by the assumption that the latest stable
>version is the best, and everyone should upgrade, you cannot assume
>upgrading is a zero-cost task, and therefore you cannot assume there
>will ever be sufficient motivation to do it.  That's a basic management
>argument, and it's not specific to Tomcat by any means.
>Naturally, I've heard the argument many times.  Since you also can't
>assume any app is bug free, eventually bugs tend to show up.  Now the
>developers have to re-learn the old version of the product, setup up a
>dev environment for the old version of the app, patch, re-test, and
>re-deploy.  This is frequently (in fact, research suggests nearly
>always) must more costly than simply keeping up with upgrades.  Then the
>company hires consultants to help them fix, and you'd be surprised how
>many people make a nice living off of these type of consulting
>assignments (any Tandy consultants on this list? ;).  This has been the
>paradigm since at least the late 70's, and appears to only be getting
>worse (again from research -- anyone on the list who reads the IEEE
>Transactions on Engineering Management is fed up with this research).
>But most developers are too busy to worry about that scenario, and it
>goes back to the resource-constraint argument: if we as a company can
>spend time on creating this new app to address an existing need, or
>upgrading the server for a completely fine working app, that's a
>no-brainer for management.
>For government, military, and externally regulated industries the
>scenario is even worse because there's a length change management and
>audit process in place typically.
>I could go on and on ;)  This is well-trodden territory, the subject of
>much discussion in various offline forums I belong to.
>Yoav Shapira
>Millennium Research Informatics
>>-----Original Message-----
>>Sent: Thursday, September 16, 2004 2:19 AM
>>Subject: Re: Why tomcat 4 or even 3?
>>What is more, a lot of app's for big companies are just forgotten or
>>have a few users, so why spend time upgrading to a newer version of
>>Paul said:
>>>Sometimes one dont need to be faster.
>>>I'm talking about a old legacy app (not critical - intranet), running
>>>very well for a couple of years in the same old server.
>>Javier Polo.
>This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged.  This e-mail
is intended only for the individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the sender.  Thank you.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

View raw message