Currently, when a Connector fails to start, Tomcat logs the exception twice (once in the protocol and once in the service) and then swallows the exception. This isn't very friendly when embedding Tomcat as it means that handling of the exception and reporting it to the user is out of the embedder's control. We'd like a couple of things to be possible: 1. Catching the exception that's thrown when the Connector is started. 2. Tomcat not to log anything This would allow an embedder to take complete control of how the problem is reported to a user. In discussing this with Mark Thomas, one possibility that he raised was a Connector equivalent of failCtxIfServletStartFails that both StandardContext and StandardHost have today.
+1 for 1) if it's not too hard, however -1 for 2) (Tomcat logs errors and stuff pretty much everywhere, there's no switch for any of them, and it doesn't make sense; please adjust the logging configuration to use some custom logger of your own instead).
> and it doesn't make sense The current behaviour makes sense given that Tomcat swallows the exception; otherwise, there'd be no way to see that a problem has occurred. If a change is made such that Tomcat can be configured to throw the exception, then I would argue that it no longer makes sense for Tomcat to also log the exception. > please adjust the logging configuration to use some custom logger of your own instead That would only work if it's possible for a logger to distinguish between exceptions that Tomcat is going to swallow and those that it's also going to throw to be caught by embedding code.
Ok so basically Tomcat needs to remove all logging I suppose. Nice. I don't think all the necessary information to produce the best logging is contained in the exception, also. Ex: How do I know if it's a bind exception or a SSL configuration error ? Your solution: dump the exception to the user and he'll figure it out. So -1, sorry, you'll have to figure things out at the logging layer, even if you don't like it.
(Calm down, Rémy.) I think the proper way to handle this is for Tomcat to change the way the exceptions are handled, here. Instead of introducing a new option (c.f. failCtxIfServletStartFails), why not just move the exception-handling to one layer higher than an embedded controller would see? That way, standalone Tomcat can still catch and log the exceptions which is appropriate, and embedded controllers can do whatever they like.
The complication - and I need to dig through the archives to find the details - is that there was a requirement that Tomcat started even if a connector failed. What we have here is two requirements for exactly opposite behavior. I suspect configuration will have to be part of the solution but if someone can find a way to do this without a new option, great.
(In reply to Mark Thomas from comment #5) > The complication - and I need to dig through the archives to find the > details - is that there was a requirement that Tomcat started even if a > connector failed. I apologize as I'm ignorant of the code in question, but isn't Tomcat's bootstrap process circumvented by an embedded controller? In that case, Tomcat can just try/catch around the Connector.start() calls and log there, no? > What we have here is two requirements for exactly opposite behavior. I > suspect configuration will have to be part of the solution but if someone > can find a way to do this without a new option, great. It's ugly, but we could also have a callback-registration that would indicate errors for certain components that failed to start. Post-start, the embedded controller could take remunerative action.
The current behaviour derives to bug 49030 and r752323. I'm still looking at options for implementing this but it does look like it is going to involve some form of new configuration option.
Fixed in 9.0.x for 9.0.12 onwards.