Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Why tomcat 4 or even 3?
Date: Thu, 16 Sep 2004 08:45:00 -0400
Message-ID: <9C5166762F311146951505C6790A9CF801FC391F@US-VS1.corp.mpi.com>
Thread-Topic: Why tomcat 4 or even 3?
Thread-Index: AcSbtRaS7iFniZBzQkOPrS+GDdiemQANNBkA
From: "Shapira, Yoav" <Yoav.Shapira@mpi.com>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>


H=
i,
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 everythi=
ng
else in life ;)  Even you abide by the assumption that the latest stab=
le
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 managemen=
t
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 t=
he
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 th=
e
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 o=
f
much discussion in various offline forums I belong to.

Yoav Shapira
Millennium Research Informatics


>-----Original Message-----
>From: POLO ARAUJO, JAVIER [mailto:javier.polo@madrid.org]
>Sent: Thursday, September 16, 2004 2:19 AM
>To: tomcat-user@jakarta.apache.org
>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
>tomcat?
>
>
>
>Paul said:
>
>> Sometimes one dont need to be faster.
>
>> I'm talking about a old legacy app (not critical - intranet), runni=
ng
>
>> very well for a couple of years in the same old server.
>
>
>
>Javier Polo.


This e-mail, including any attachments, is a confidential business com=
munication, and may contain information that is confidential, propriet=
ary and/or privileged.  This e-mail is intended only for the individua=
l(s) to whom it is addressed, and may not be saved, copied, printed, d=
isclosed or used by anyone else.  If you are not the(an) intended reci=
pient, please immediately delete this e-mail from your computer system=
 and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org