Re: [5] hotfixes
Tim Funk wrote: One feature of enterprise ready software is the ability to apply small patches to an existing system. For example: if a single class (or a few classes) have an error and that is the only fix - it might be nice to deploy a jar (or jars) that have a higher classloader preference. (But not parent loading) This might be nice for those who want bug fixes but they don't (or can't recompile everything) and need a bug fixed and can't wait for the next release. (Due to PHB syndrome) The alternative is to make the unpack the jar into the classes dir. This can also be error prone when cleaning up if the user has their own classes. 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--MM--hh-mm-ss.jar (or similar) first and sorting those files by name so the newest ones get loaded first. Comments? Sounds like a good idea :) I have released hotfixes in the past, in the form of an archive which contained unpacked classes (which have a priority over the JARs). Distributing a timestamped JAR seems cleaner. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5] hotfixes
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--MM--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 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]
Re: [5] hotfixes
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--MM--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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] hotfixes
Hello, 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 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--MM--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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] hotfixes
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. -Tim Shapira, Yoav wrote: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
RE: [5] hotfixes
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]
Re: [5] hotfixes
Tim, If the problem is that bug fixes have not made it into a release in a timely manner, then we should be doing releases more frequently. Or put back in place the nightly builds. Using hotfixes to bridge the gap between releases is overkill IMHO. I am still -1 on adding this. Glenn 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. -Tim Shapira, Yoav wrote: 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. - 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]
Re: [5] hotfixes
Thats ok with me, I'm glad this was discussed in case this topic comes up in the future. -Tim Remy Maucherat wrote: After reading everyone's comments, I will vote -1 to the hotfix proposal, because: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
