Am 5. Juli 2020 11:28:40 MESZ schrieb Michael Osipov <micha...@apache.org>: >Am 2020-07-02 um 21:30 schrieb Thomas Meyer: >> Hi, >> >> What are your opinions on providing a RFC7807 based ErrorReportValve >as part of Tomcat default distribution? > >Thomas, this has been bugging me for a while. Let me share some >thoughts >on this, I'll limit my experiences with Tomcat, Spring Web and Zalando >Problem (including it's web module): > >Mark, please correct me if my citation of the Servlet API is wrong. > >* The Servlet API has been designed where the only clients where >browsers >* The Servlet API mandates that all invocations of >HttpServletResponse#setError() must yield in a HTML page and this >*cannot* be changed by defult >* Even if you write a REST API or explicitly use @RestController Spring > >will still invoke #setError() although it makes no sense. I consider >this to be a conceptual flaw in the Spring framework. > >Before we continue which issue do you want to solve? Tomcat produced >errors or by a framework?
It's about tomcat produced errors: There are multiple webapps deployed to tomcat all under non-root context path. Some webapps use spring framework, for these webapps an CustomErrorController is installed so always a JSON response in a given JSON layout is done. Some webapps are pure servlet based, here an error-page entry in web.xml and an ErrrorSerlvet is used to also have the same JSON layout as above for all possible errors. But because of some race condition in deployment scripts for multi node setup, some class files weren't copies correctly, and tomcat ErrorReportValve was triggered with NoClassDef error. So much for the context. I guess I'll write an JsonErrorReportValve and install it in lib/ so deployment will always response with same JSON layout in all circumstances, e.g. failed deployment or access to unknown context path. > As for the framework, I would prefer to file > >an issue with Spring Framework first and see what the devs say because >this would solely solve a symptom. > >Michael > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
