2011/11/6 Konstantin Kolinko <knst.koli...@gmail.com>: > 2011/11/6 Mark Thomas <ma...@apache.org>: >> >> I'm in two minds whether to apply this patch before or after the 7.0.23 >> tag. There are clearly issues here that need fixing but the patch is >> quite invasive. I'm leaning towards tagging after the patch is applied. >> Thoughts? >> > > In short: I think there are two issues > a) what FailedContext solves > b) touching context.xml causing redeploy instead of reload > > I think a) needs to be solved asap and likely to be backported.
I mean, handling deployment failures. Being stumbled here I agree that looks like it is better to cut 7.0.x as is and take several days after that to though of a better solution. > b) can be postponed. > > Regarding b) - remember that order of entries in redeploy list used by > autodeploy check is very important (because files ##(n+1)..last are > deleted if file #n is touched). I am not yet sure that the patch is > safe adding context.xml there. There is StandardContext#setDefaultContextXml() method. Maybe implement something like that in FailedContext. In those places where you are replacing addWatchedResource() with addRedeployResource() - maybe do not do such replacement. Instead of that in HostConfig#addWatchedResources() or elsewhere use the value of StandardContext#getDefaultContextXml() and add that file to redeploy resources explicitly. Thusly we will have more precise control on their order. Maybe in HostConfig$DeployedApplication.redeployResources do store explicit flag whether the resource is supposed to be deleted on undeploy. (Instead of checking file paths before deleting the resource in HostConfig#checkResources()). Maybe I am just afraid of those path checks in #checkResources() and adding a comment there can resolve it. > ==================== > Regarding RequestFilterValve: Question is solved. Updated the valve implementation earlier today and merged to TC7. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
