Howdy, I would also vote -1 as I mentioned before. It's another source for confusion and bugs, and does not add much in practice I think. The small bugs that necessitate one class changes are typically not showstoppers, but more the PITA category that Tim referred to. To the individual developer/server admin, it's either: - Sure it's PITA but I don't have tom worry; file a bug report and wait for the next release, or - This is so annoying I can't stand it and will put my own class files here to fix it
If something is a real showstopper, we're going to want a real release to fix it anyways, with documentation, testing, etc. Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: Remy Maucherat [mailto:[EMAIL PROTECTED] >Sent: Friday, July 18, 2003 11:52 AM >To: Tomcat Developers List >Subject: Re: [5] hotfixes > >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] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
