[Bug 60152] Allow exceptions from Connector.start() to be caught and handled in code that embeds Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=60152 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Mark Thomas --- Fixed in 9.0.x for 9.0.12 onwards. -- 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
[Bug 60152] Allow exceptions from Connector.start() to be caught and handled in code that embeds Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=60152 --- Comment #7 from Mark Thomas --- 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. -- 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
[Bug 60152] Allow exceptions from Connector.start() to be caught and handled in code that embeds Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=60152 --- Comment #6 from Christopher Schultz --- (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. -- 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
[Bug 60152] Allow exceptions from Connector.start() to be caught and handled in code that embeds Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=60152 --- Comment #5 from Mark Thomas --- 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. -- 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
[Bug 60152] Allow exceptions from Connector.start() to be caught and handled in code that embeds Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=60152 --- Comment #4 from Christopher Schultz --- (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. -- 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
[Bug 60152] Allow exceptions from Connector.start() to be caught and handled in code that embeds Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=60152 --- Comment #3 from Remy Maucherat --- 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. -- 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
[Bug 60152] Allow exceptions from Connector.start() to be caught and handled in code that embeds Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=60152 --- Comment #2 from Andy Wilkinson --- > 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. -- 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
[Bug 60152] Allow exceptions from Connector.start() to be caught and handled in code that embeds Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=60152 --- Comment #1 from Remy Maucherat --- +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). -- 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
