Using jakarta-tomcat-4.0.4-LE-jdk14.exe, index.html and jakarta graphics files in the ROOT directory are overwritten on install. Old files are deleted, and the new files written in their place.
Maybe it could be fixed, but updating an existing installation using the installer isn't a very good idea. The recommended way is uninstall / install.
Changing this to an enhancement request to include an upgrade option in the installer. Whilst this would be nice to have, there are a number of potential issues such as updates to the configuration files that make this tricky to implement.
Any chance this could be looked at for Tomcat 5?
Some random thoughts on this. If this is implemented, separating CATALINA_HOME / CATALINA_BASE is one way to go since that will simplify the upgrade process. That then raises a number of additional questions: - Are multiple HOMEs supported? If so how? - Are multiple BASEs supported? If so how? - Does uninstall remove a HOME, all HOMEs? - If a HOME is uninstalled what happens to BASEs using it? That could all get quite complicated. The other approach is to just update the binaries (*.exe, *.jar) leaving the config as is. The more I think about it, the more 'do-able' this sounds. May need an upgrade specific read-me for any recommended config updates (changes to defaults, new settings etc). I'm leaving this open as I think it is worth doing (well, at least worth looking at in more detail) but it feels like a fair amount of work to get right.
There's also the problem of somehow merging configurations: sometimes, server.xml is updated even within a stable line. The safest thing to do is simply leave server.xml alone, but we might still run across problems there. How traumatic are changes allowed to be within a particular version line (6.0.x)? For example, the JreMemoryLeakDetectionListener was introduced at some point in 6.0.x but hasn't always been there. That's not a problem as /adding/ something isn't a big deal. Do we ever /remove/ anything that might cause a startup failure? Similarly, sometimes configuration defaults change: do we have to detect whether the old defaults are in use and then explicitly set them to their old default values in server.xml/web.xml/context.xml? The process of upgrading could seriously break someone's configuration.
I'm still mulling this one over. I'm currently on the fence between WONTFIX and the replace the JARs upgrade method (with a your config might break caveat). If it does get implemented, it will be for Tomcat 7 onwards.
While this could get complex, I suspect that on the whole it will save committer time. An installer with an upgrade option and a big fat warning would reduce those ever-present requests on the Tomcat mailing list for "How do I upgrade Tomcat?" I accept they might just change to "why is this big fat warning here", though.
There are complications with the "just over-write the binaries and JARs" and include: - required changes to config files - changes in JAR names (e.g. JDT updates) I am leaning more towards WONTFIX as further complications are identified.
I've come to the conclusion that this is simply too complex a problem to solve for the benefit it would bring. To upgrade safely would require a switch to using separate CATALINA_HOME / CATALINA_BASE which would make the installer more complicated. The installer would also need to be able to patch the configuration files to add, for example, additional permissions required by the security manager or to modify defaults in web.xml, context.xml or server.xml. This introduces way to many complexities. While we could provide a "simple" upgrade process this would come with a stack of caveats and would likely require manual intervention to complete correctly. Given that the installer now allows side-by-side installs of multiple versions, the 'manual' upgrade process of install a new version and copy your webapps is likely to be the simplest.