Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [5] hotfixes
Date: Fri, 18 Jul 2003 09:18:47 -0400
Message-ID: <9C5166762F311146951505C6790A9CF834646E@US-VS1.corp.mpi.com>
Thread-Topic: [5] hotfixes
Thread-Index: AcNMzs4+ihR2NW4FSza686CS4n118AAXwz4w
From: "Shapira, Yoav" <Yoav.Shapira@mpi.com>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>


Howdy,

>Currently o.a.c.startup.ClassLoaderFactory just does a standard
directory
>listing. It might be nice to have the directory listed sorted in some=

>manner
>so files with certain attributes might be loaded first.
>
>I was thinking of either
>- sorting by date
>- looking for hotfix-YYYY-MM-DDDD-hh-mm-ss.jar  (or similar) first an=
d
>sorting those files by name so the newest ones get loaded first.
>
>Comments?

There used to be servers that did this (IPlanet and JServ come to mind=
,
both using alphabetical sorting), and the amount of hassle that caused=

to developers was huge.  Even to date, I see developers who rely on ja=
r
loading order to resolve having two classes with the same name in the
JVM.

I don't think this is a good idea.  In the case for a hotfix, I would
rather see a new jar altogether, replacing an existing jar.  Not an
addition, not an expansion, nor some fancy overriding mechanism.  It
significantly increases classloading debugging capability ("which jar
did this class really get loaded from?").

I also tend to not fully agree with your beginning premise:

>One feature of enterprise ready software is the ability to apply smal=
l 
>patches to an existing system.

That's a nice to have, not essential, and a deterrent due to the above=

reasoning in the worst case.  I would consider tomcat enterprise-ready=

now, without this feature per-se.

Perhaps I'm misinterpreting what small patches are, though?  Did you
have examples in mind?  I think it's the component owner's
responsibility to provide the fix/patch, and to do so in the manner be=
st
fitting the component.  In most java cases, I think that's an updated
jar.  If the fix requires many jars, then probably the product wasn't
properly divided into modular jars to start with.

I don't mean to sound extreme on this ;)  I've heard far worse ideas.
But I think for a general purpose server this causes more possible
confusion and problems for users than it does good.

Yoav Shapira


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-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org