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.

Remy



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to