On 02/11/2011 15:35, Konstantin Kolinko wrote:
> 2011/11/2 <ma...@apache.org>:
> Also s/redploy/redeploy/ in some Javadoc.
Fixed for next iteration of the patch.
> The removeWatchedResource() method in the patch is NOOP instead of
> calling renamed method.
Also fixed.
> The following in StandardContext.java does not look backwards-compatible:
> - fireContainerEvent("addWatchedResource", name);
> + fireContainerEvent("addReloadResource", name);
> and
> - fireContainerEvent("removeWatchedResource", name);
> + fireContainerEvent("removeReloadResource", name);
>
> Better keep the old name of "watched" and just add the new one of "redeploy".
> In all places the "redeploy" list is new and parallel to the old "watched"
> one.
Fixed too.
>> The one thing I don't like is that a change to conf/context.xml that
>> breaks the file effectively kills the instance until the problem is
>> fixed and the instance re-started.
>
> Looking at HostConfig.checkResources(DeployedApplication) note several
> ExpandWar.delete() calls. The order is important there. If redeploy
> resource #i is missing or updated it deletes all following redeploy
> resources starting with #(i+1).
>
> With this behaviour it is better not to let a user to control this
> "redeploy" list.
Fair point. I'll remove them from the docs, the digester and JMX.
> Regarding the original task of what happens when context.xml is
> touched or edited: redeploying deletes the work dir, along with all
> persisted sessions and all compiled JSPs. (ContextConfig.destroy()
> triggered by Host.removeChild() does the deletion)
>
> It is an enormous price to pay for editing an AccessLogValve
> configuration or whatever is important in context.xml. I'd prefer a
> solution that does not delete the work dir.
I do see where you are coming from here. There are times when it isn't
necessary to clean out the work dir or the sessions. However, figuring
out which is which is really tricky. I'm not even sure it is completely
possible. We need to use redeploy else the Context configuration won't
get re-read. I think the answer is to use parallel deployment if you
don't want to lose sessions etc although that doesn't help with the work
dir. There is always pre-compilation for that.
I don't think a one-size-fits-all solution is possible here but I think
we do have options that cover the key use cases.
I'm still looking at:
- recovery after fixing the broken file
- not deploying an expanded dir if the context.xml in
conf/Catalina/localhost is broken.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
