2011/11/2 <ma...@apache.org>:
> Konstantin Kolinko <knst.koli...@gmail.com> wrote:
>
>>2011/11/2 Mark Thomas <ma...@apache.org>:
>>> On 01/11/2011 22:39, Mark Thomas wrote:
>
>>> My first stab at a patch for this is at [1]. Comments welcome.
>
>>>http://people.apache.org/~markt/patches/2011-11-01-redeploy-trunk-v1.patch
>
>
>>Quick review - several typos:
>>
>>mbeans-descriptors.xml:
>>- typo "findRedployResources"
>>- "Path to the resource, relative to docBase" - It is "either absolute
>>or relative to docBase".
>>
>>docs: s/if is is updated/if it is updated/
>
> I'll get those fixed for the next iteration.
Also s/redploy/redeploy/ in some Javadoc.
The removeWatchedResource() method in the patch is NOOP instead of
calling renamed method.
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.
The only place where meaning changes is
HostConfig#addWatchedResources() that now processes both types.
> 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.
BTW, checkResources(DeployedApplication) deletes reload resources on
auto-undeploy as well, but first checks their path.
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.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
