Hi! I am working on a patch that prevents RequestFilterValve from starting on configuration errors.
Current versions: http://people.apache.org/~kkolinko/patches/2011-10-26_tc6_RequestFilterValve_v3.patch http://people.apache.org/~kkolinko/patches/2011-10-26_tc55_RequestFilterValve_v3.patch I am testing on host-manager webapp by adding the following valve: <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="(" /> The following are results and caveats: 1. In Tomcat 6 and 5.5 to reproduce the error you have to add the broken Valve both to conf/Catalina/localhost/<webappname>.xml and to webapp/<webappname>/META-INF/context.xml If the valve is added only to conf/*, the XML file deployment fails, but Tomcat will later try to deploy the application again from webapps folder and this deployment may be successful. Thus was my confusion that the protection appeared to be not working. The exception is printed, but the app works, because it is redeployed afresh, ignoring the modified XML file. In Tomcat 5.5 I was not observing this, because host-manager is not present in webapps, but I can reproduce such successful redeployment with jsp-examples. I think it would be better if broken context file in conf would prevent deployment from webapps as well. 2. Tomcat 6 and 5.5 return error 403 when I try to access the failed webapp. It is good, but I do not understand where it comes from. I would expect 404 as if the app has not been deployed, or 503. 3. In Tomcat 5.5 failed deployment of host-manager results in autodeployment process repeating deployment attempt every 10s and printing the error in the logs. Tomcat 6.0 does not attempt redeployment. Nothing seriously wrong with it. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
