>Very bad idea. Search the archives for a long list of things that go >wrong when you start changing the class path. Not to mention that would >make the new driver visible to all web applications not just the web app >that needed the new jar file. And you'd need to restart Tomcat for the >changes to take effect. That means downtime unless you use load-balancing.
I'll do a search and see what I can find what kinds of things go wrong with changing the class path. This is a bummer because this was going to be my fallback solution. :( > Won't help. The servlet spec requires that classes in the web > application take priority. The only quote I was able to find from the servlet spec was: "It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs." Seems to me that there is some wiggle room there. Besides Websphere actually by default deploys its web application "parent first" completely ignoring the above recommendation. :) > Even if the solutions would work (which they won't) they seem a lot more > complex than > - unpack war > - replace driver jar > - pack war > - deploy through manager Here are a couple of the problems I have with the above approach: * If I'm administering an environment with 20-30 tomcat apps all of which require the new database driver this is a rather more difficult process for middleware engineers (not developers) to perform than simply (Copy this file into *this* directory, restart app) * It would seem that the change tracking of a process like that above would be very difficult. It would be hard to answer questions like "What patches have I applied to these 20 applications in production?" If there were simply a folder with the patches right there then it becomes very easier to see how this running application's configuration differs from the configuration the archive was built with. This becomes more and more important the older an application gets and the more patches applied to it. > That would update the driver for the app with zero downtime. What is the > issue with this approach? This may just be my organization's standard but we never hot deploy in production. We're too scared of permgen errors and other potential inconsistencies plus we have a load balancer. However, this may work for others so point taken. Mike -- View this message in context: http://old.nabble.com/Classloader-between-Web-application-and-system-loader-tp27154908p27170181.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
