Logging capabilities

[amzn-paunort]

When serialization or deserialization encounters an (expected) issue, we should be able to log them to our users to be resolved. In particular, this would be a necessity in non-fatal serialization issues, where we cannot throw a serialization/deserialization exception.

I think relying on Apache's Common.Logging would be a reasonable choice for this, since it does not enforce a specific logging implementation on our consumers, similar to Java's SLF4J.

This came up in my work on #29, where the ability to log would allow us to report this field naming conflict as a non-fatal warning to the user, instead of either a) silently ignoring the field or b) throwing some sort of name conflict error.

[guyilin-amazon]

It would be great if the object mapper could log messages for behaviors that are not clear enough from the specifications. Besides logging, we could also add more instructions to the spec to clarify unclear behaviors.

I don't think the logging capabilities would be a launch blocker for public release, as we may need more feedback for the current object mapper behaviors after the public release, and start to update doc/add logging/make behavior changes based on the feedback.

[popematt]

A serialization library should not log any of the data that it serializes because that has the potential to expose sensitive data in the application logs. Instead, consider an approach where the serializer can be configured with an optional callback function that consumes an object with the details of the non-fatal error. (One might even say that the non-fatal error is an event.)

Here's a strawman example of an non-fatal event (as Ion) to help illustrate the benefits of this approach:

{
  message: "Field name conflict",
  location: { row: 15, col: 28 },
  data: Customer::{ name: Bob, name: Joe },
}

The benefits of this approach are that

• This library doesn't need to pull in any new dependencies
• users of the library can customize what information gets logged; they may choose to log only the message, the message and location, etc.
• users of the library can customize how non-fatal error events are handled by ignoring some of them or raising an exception for others