Please submit a documentation change.
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: tomcat-user-unsubscribe@(protected)
> For additional commands, e-mail: tomcat-user-help@(protected)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)
