tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <>
Subject RE: [5] hotfixes
Date Fri, 18 Jul 2003 13:18:47 GMT


>Currently o.a.c.startup.ClassLoaderFactory just does a standard
>listing. It might be nice to have the directory listed sorted in some
>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 and
>sorting those files by name so the newest ones get loaded first.

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 jar
loading order to resolve having two classes with the same name in the

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