On 25/04/2012 15:57, Christopher Schultz wrote: > Pid, > > On 4/23/12 9:50 PM, Pid wrote: >> On 23/04/2012 15:06, Christopher Schultz wrote: >>> Christoph, >>> >>> On 4/22/12 11:55 AM, Christoph Maser wrote: >>>> Chris, >>> >>>> Am Donnerstag, den 19.04.2012, 18:21 +0200 schrieb Christopher >>>> Schultz: >>>>> Christoph, >>>>> >>>>> What about the webapp itself performing its own health-check >>>>> as a last step of deployment, and throwing an exception >>>>> (thereby preventing Tomcat from bringing it into service) if >>>>> things aren't in working order? >>> >>>> this is the obvious way to do it as it is now. As I said >>>> before that way one looses the access to the wapps status >>>> pages. >>> >>> So you want the webapp both up (for status) and down (for >>> traffic) at the same time? Tomcat certainly can't manage that for >>> you. >>> >>> If you need "status" on a failed-deployment, why not dump it to a >>> file or something like that? > >> Or use JMX rather than HTTP to acquire status information. > > In theory that sounds good, but the webapp needs to be deployed in > order to interrogate it via JMX. Once it's deployed, it's in service > (even if it's broken) and the system falls apart.
Which 'system falls apart'? JMX provides an alternative route to determine application status that is not impacted by whether the app is up or down. If the app is not deployed there will be no associated MBeans. If it is deployed but not running the status attribute of the WebModule MBean will indicate this. An HTTP connection is much less reliable and trying to do what the OP is asking is unlikely to provide a universally reliable result. If the app is well behaved then it could start up enough to report it's health, given some components not starting properly - but I think the OP is asking for something else. p -- [key:62590808]
signature.asc
Description: OpenPGP digital signature
