In the AbstractHandlerExceptionResolver the log level for all responses handled by the resolveException method is set to WARN, in bold below. The problem is that not all responses handled by the method are responses that should be treated at the WARN log level, as normal responses to the end user can be handled by this method.
We're only really logging resolved error views at warn level... which doesn't really qualify as a normal user response. REST-like translations to a certain response status etc will never return a ModelAndView there to begin with.
If you're unhappy with the warn-level logging for error views, consider setting your HandlerExceptionResolver's warnLogCategory property to null or overriding the logException method in a custom subclass.
Assigning this to Rossen Stoyanchev for further review. We may of course fine-tune this in 4.3 if there turns out to be some common scenario where warn-level logging is irritating.
Indeed the logging occurs when the resolver returns a ModelAndView which indicates the exception was resolved by the handler and an (error) view is about to be displayed. Can you clarify what you mean by "normal responses" in this context? And why switch to DEBUG altogether. Shouldn't that be for "normal" only which leads back to the question about how you would identify a normal response within an exception resolver.
What I meant with a normal response is e.g. if an exception is thrown by a component in an application and that exception signals that some data hasn't been found and that a 404 should be returned to the client of the application. That exception will be caught by an exception handler and mapped to a 404 response. This flow will pass through the AbstractHandlerExceptionResolver and lead to a WARN log message that in this case IMO is not appropriate as even though it's not a 200 OK flow, it's not something that warrants a WARN log message.
It turns out that this default warn logging is rather recent: introduced through #17691 for 4.2. We should fine-tune this to only apply to certain kinds of responses then, not firing in case of a plain 404 or the like.
In a normal production environment I would run with Info level (which includes warn level) for most of the categories. If in the DefaultHandlerExceptionResolver the warnLogger is set on line 100 and all methods return an empty ModelAndView object the method logException(Exception ex, HttpServletRequest request) in AbstractHandlerExceptionResolver will always be called and logs out the exception because both conditions (warnLogger different than null and warnLevel is enabled) are met.