Spring does not log deserialization / marshalling errors to the console [SPR-13100]

[spring-projects-issues]

Ole K Ersoy opened SPR-13100 and commented

When submitting dates that Spring does not know how to desearialize it's possible to see the exception in the REST response. For example I can do the following:

    response =
        given().auth()
            .basic(ADMIN_USER, PASSWORD)
            .contentType(APPLICATION_JSON_CONTENT_TYPE)
            .body(updatedJSON)
            .when()
            .put(contactRestPath);

    System.out.println(response.getBody().asString());

I was running the above in a test, however GSON did not serialize the date to something Spring could read, thus the corresponding controller method (Update method) was never called. It would be nice if Spring could log the exception to the console, so that what is happening is more clear.

SIDE NOTE:
GSON has been around for a while, so I assumed that it would have a serialization/desearialization strategy that fits well with most rest frameworks:
google/gson#650

Cheers,

• Ole

---

Affects: 4.2 RC1

Issue Links:

• Inappropriate warn logging in AbstractHandlerExceptionResolver (e.g. for 404 status) [SPR-13596] #18174 Inappropriate warn logging in AbstractHandlerExceptionResolver (e.g. for 404 status)
• Consistent warn logging without stacktrace in Portlet HandlerExceptionResolver [SPR-13611] #18189 Consistent warn logging without stacktrace in Portlet HandlerExceptionResolver

[spring-projects-issues]

Juergen Hoeller commented

Sébastien Deleuze, could you have a look at this for RC2? I suppose we are logging something somewhere but apparently it's not obvious enough...

Juergen

[spring-projects-issues]

Sébastien Deleuze commented

Indeed, I also think we should improve serialization/deserialization exception logging. But we should also be careful about not polluting the log too much.

Deserialization failures due to bad input format or because Jackson does not work on POJO without default constructor, occur very frequently, and there is no feedback when DEBUG log level is not enabled.

This commit introduces the following changes in AbstractHandlerExceptionResolver:

• warnLogger used to log serialization/deserialization exception is enabled by default
• the exception message is now logged instead the whole exception stacktrace
• warn logging is only performed if doResolveException() return a non-null ModelAndView, in order to avoid logging multiple times the error in the log.

Logging by default serialization/deserialization errors is not a small changes, but given that the changes I made allow to reduce what is logged from 3 full stacktraces to 1 exception message, and given that it is possible to disable warn logging by calling AbstractHandlerExceptionResolver.setWarnLogCategory(null), I think that's interesting to introduce in our upcoming 4.2 RC2 release.