https://bz.apache.org/bugzilla/show_bug.cgi?id=68919
--- Comment #3 from Christopher Schultz <ch...@christopherschultz.net> --- (In reply to Michael Osipov from comment #2) > I am not convinced by either approach because in any case it would require me > to deploy a ROOT application with Tomcat privileges to properly fetch the > URL and check whether the application is truly stopped. I don't think so. If Tomcat cannot route a request to a non-ROOT application, the ROOT application will receive the request instead. So, for example, if you expect a resource to be available at /myapp/resource but the /myapp application is not running for whatever reason, then /myapp/resource will be served by the ROOT application. There is no reason for the ROOT application to then turn-around and re-request /myapp/resource from Tomcat "to see if it's working". You already know its NOT working since it was routed to ROOT. > > Tomcat rewrite Valve > This is static, I should dynamically be able to determine that the requested > webapp is down See above. I think Tomcat provides that without you having to probe anything. > > plain JSP + <error-*> configuration in web.xml > How? The status is issued by the container, how am I supposed to change the > status code reasonably from a JSP. Looks wrong to me. If /myapp/resource is not available, it will be served by ROOT. Here is where you get to pick the HTTP status code. Tomcat will not say "oh and by the way, /myapp/resource was supposed to be served by /myapp but I had to give it to you, instead so something is definitely wrong". Instead, the simple fact that ROOT is handling the request means that /myapp is not running so ROOT "knows" something is wrong already. Just return a 503 or 404 or 123 from whatever mechanism you want. > > Custom Java code that you write > Too sophisticated honestly. > > I think that it is best configured at <Host> or <Context> level inside of > Tomcat. I'm suggesting this is already possible: just configure a ROOT context inside a <Host> and you are done. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
