Historically, only reloadable was being done. This caused a lot of questions as to why changes in web.xml were not being picked up. As some refactorings came, it became easier to perform a stop, then start on the webapp instead of classloader reload.
-Tim
Bill Stilwell wrote:
Hello,
I was unsure if this or -dev was the best place to send this, so I decided to go with user first.
I recently spent some time tracking down why we would get application restarts when code changes were pushed to our production environment, despite having reloadable="false" in the DefaultContext. Via some digging around in the source, it turns out that if you have liveDeploy="true" and web.xml is modified, the application will be stopped and started.
Personally, I find this behavior unexpected (and, as far as I can tell, it's not in the user documentation). I can achieve what I expect with liveDeploy="false" and reloadable="false", but I think it would be much clearer for users if only the reloadable setting was required to achieve no reloading unless done explicitly via the manager or at restarts.
The relevant code is here: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/HostConfig.java
And the method checkWebXmlLastModified() is what controls this behavior. The original version of this code respected the reloadable setting.
Is this worth filing a bug w/patch to request a code change? Or am I better off submitting a documentation change - i.e., are my expectations here out to lunch? :-)
Thanks Bill
--------------------------------------------------------------------- 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]
