Is there any way to force Tomcat 4.1.18 to physically unpack .war files it finds in /webapps amidst the presence of *ANY* kind of durable server-specific configuration for that warfile's context?
>From browsing the mailing list archives, I've gathered that Tomcat will RUN webapps >from warfiles if it finds a context element of the same name in server.xml, but it >refuses to physically extract the files into /webapps... ... but another post hinted that Tomcat can be coaxed into doing it anyway, as long as the context element is removed from server.xml and moved into an xml file of its own in /webapps with the same root name as the warfile. I stopped Tomcat, deleted its workfiles, built a fresh warfile, moved the context element from server.xml into its own xml file in webapps, and restarted Tomcat. And it still didn't extract the files. I scrounged a little more, and discovered that Tomcat won't complain about an "unpackWARs" attribute in the CONTEXT element, and if it's present, Tomcat seems to care whether its value is true, false, or some invalid value, but nevertheless seems to do nothing with the value anyway. The third possibility someone mentioned (making the context element's standalone xml file part of the warfile itself in META-INF) isn't viable, because it would defeat the whole purpose of putting the info in the context element of server.xml in the first place -- storing the "durable" config info that's specific to the webapp running on that particular machine that we WANT to survive warfile replacements/upgrades, but DIFFERENT when the webapp runs on other servers. Put another way, the same webapp is getting deployed from copies of the same parent warfile to two different servers, at two different locations, each of which has its own database. The database info is configured as a resource bundle in server.xml within the context element for the webapp. The webapp is also picking up values from "GlobalNamingResource" elements, but we can stick THOSE outside of the context element anyway, so it doesn't matter. The general idea being that server.xml (almost) never changes, but the warfiles get replaced all the time... but since they're picking up all their location-specific details from server.xml, the physically unpacked files can be wiped with impunity as long as they're promptly replaced with new copies from the new warfile. Even though the unpacked physical files can easily be replaced and don't need to be durable, and in fact SHOULD be wiped in their entirety the moment Tomcat finds a new warfile to deploy, various classes written over the past few months will die a horrible death if they don't, in fact, find a physical file sitting in the right place on the server's hard drive. So... *IS* there any way to force Tomcat to watch for new warfiles, and physically unpack & use them whenever they change, BUT tolerate the presence of durable context configuration info somewhere besides the warfile itself (either within server.xml, or somewhere Tomcat can find it, like giving the context element its own xml file in /webapps)?
