On 14/11/2011 05:54, Konstantin Kolinko wrote: Note: "Fixed" below means I have fixed the issue locally and will include it in the commit.
> 1) s/Redploy/Redeploy/ in several comments. Fixed. > 2) In HostConfig.checkResources() there are three occurrences of the > following code: Fixed. > 3) Testing redeployment. Thanks for this. It is a useful recipe. > Tests: > 1. touch context.xml -> OK, all redeployed > 2. touch context.xml.default -> OK, all redeployed > 3. touch examples.xml -> FAIL, redeployed examples app, but it deleted > "context.xml.default" (causing redeployment of all other webapps) > Now shutdown Tomcat, restore "context.xml.default" and start Tomcat Fixed as a result of the fix for 2) above. > 4. delete examples.xml -> Examples app is undeployed, but is instantly > deployed again as "web application directory". It is strange. Is it > expected? On first inspection, not what I expected. On reflection, I think it is. Consider the sequence (when context.xml files are copied to conf/Catalina/localhost - new dir with META-INF/context.xml is copied to appBase - context.xml is copied to conf/Catalina/localhost during deploy - conf/Catalina/localhost/newapp.xml is edited (redploy) - conf/Catalina/localhost/newapp.xml is deleted (redploy) - At this point the original context.xml is copied from META-INF I think an argument can be made for this to work either way. Given the current approach has been like this since the early days of 5.5.x, I plan on leaving it as is. > 5. rename "context.xml.default" -> OK, all redeployed > 6. rename "context.xml" -> OK, all redeployed > > I have not tested what happens if I deploy a war file. I repeated the above with examples -> examples.war and all behaved the same way. > 4) There is StandardContext#setDefaultContextXml() method. > I do not see it being called by Tomcat code, nor I see it documented > in config/context.html. I assume this is for the embedded case. > 5) FailedContext is used in HostConfig class only. > > Actually HostConfig#digester just preparses the context.xml file: it > processes only the root <Context> element and its attributes. This is by design. If the Context element and attributes are OK then a valid context object can be created. Whether or not it can start is a different problem. FailedContext is intended for use when the config is so badly broken that Tomcat can't determine what class it should be using for the Context object or there is some issue configuring it. Is there scope for further improvement, clarification around deployment? Sure. But I don't think this issue is place to make those changes. I'll be committing the amended patch shortly. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
