tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Algesten <>
Subject Re: [5] hotfixes
Date Fri, 18 Jul 2003 14:54:02 GMT

I don't agree with Glenn or Yoav.

For each tomcat 4.1.x version I use there are a couple of things I have 
to fix over and over again. My approach to making changes is: 1) take 
the official binary release of tomcat and 2) make *minimal* changes to 
address the problems I have with it.

Currently I end up with compiling a couple of java classes manually 
with the destination directory being the server/classes such as:
javac -d /jakarta-tomcat-4.1.24/server/classes

I strongly don't want to replace the whole 'catalina.jar' because of my 
tiny change (risking screwing something up unintentionally).

I can clearly see a benefit of also having an option to deploy my 
changes as a jar instead of the .class files I now end up with. I 
wasn't aware that the .jar files were not sorted alphabetically (and 
that explains some trouble I've had in the past trying to rely on it). 
I strongly suggest they should be, it doesn't hurt and will probably 
help silly users like myself.

However I'm not sure about a 'hotfix-' kind of prefix for jarfiles 
since it is not explicit enough (you have to know you can create a file 
with that name and that it will be priorities over other jar files). I 
think a better approach would be to have a 'lib-hotfix' directory so 
you get a visual indicator that the possibility of hotfixes exist.


On Friday, July 18, 2003, at 02:32 PM, Glenn Nielsen wrote:

> Well stated, I agree with your concerns.
> Shapira, Yoav wrote:
>> 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 
>>> and
>>> 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 
>> jar
>> 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 
>>> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message