tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [5] hotfixes
Date Fri, 18 Jul 2003 15:51:51 GMT
Tim Funk wrote:
> Yeah, I am scared of side effects too. This funtionality will be helpful 
> in the following situations:
> - My previous post where the access log doesn't print '+' in front of 
> the offset
> - ExtendedAccessLogValve printed the date instead of bytes (recent patch)
> - The recent Connector fixes we have seen for SSL related issues
> - JDBC, JNDI realm fixes
> - Misc valve or clustering fixes
> In all of the above - they are for bug fixes that don't warrant an 
> immediate release. They are usually for fringe cases where it makes 
> tomcat a PITA to use if not fixed.
> If one chooses not to use this feature, then the current functionality 
> stays the same.
> The patch I have in mind will not include the webapp classloader. Since 
> the spec doesn't seem to define a jar order - I prefer not to impose one.
> Currently a user has 2 workarounds:
> - Take the milestone source tree and apply the patches and build
> - Build from HEAD
> - Place the fix in XXX/classes
> The first two scenarios is a lot of work and very risky since other 
> unintended changes can easily be introduced. (At least the HEAD method is)
> The third scenario can be hard to maintain from an admin point of view 
> if the user also uses their own classes in the lib directory.
> I also like Martin 's idea of possibly introducing another directory 
> called lib-hotfix. That seems cleaner and clearer than a date (or file) 
> based sort.

After reading everyone's comments, I will vote -1 to the hotfix 
proposal, because:
- people will abuse it, have *lots* of hotfixes installed
- the subsequent bugs being reported will be harder to debug given the 
increased difficulty of reproducing the user's configuration
- users will basically expect us (= me the RM) to release one hotfix for 
every bugfix, which is something I don't want to do
- hotfix conflicts and incompatibilities
- added complexity in the container to manage the hotfixes (the 
container needs simplification whenever possible :) )
- the HTTPd project doesn't do it, for a very similar product; OTOH, M$ 
does it; one of the vendors is IMO more trustworthy than the other (ok, 
it's a bad argument ;-) )

Note that I did release hotfixes in very specific cases in the past, for 
security related problems.


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

View raw message