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 StandardContext.java
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.
Martin
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 standarddirectoryThere used to be servers that did this (IPlanet and JServ come to mind,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?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
