klog 2.30.0, logr 1.2.0, zapr 1.2.0

The new releases fix logging of KObj in JSON output: klog implements the new
logr.Marshaler interface and zapr uses it instead of Stringer when logging the
ObjectRef created by KObj.

vendor/github.com/go-logr/logr/logr.go

@@ -21,7 +21,7 @@ limitations under the License.
 // to back that API.  Packages in the Go ecosystem can depend on this package,
 // while callers can implement logging with whatever backend is appropriate.
 //
-// # Usage
+// Usage
 //
 // Logging is done using a Logger instance.  Logger is a concrete type with
 // methods, which defers the actual logging to a LogSink interface.  The main
@@ -45,7 +45,7 @@ limitations under the License.
 // LogSink implementations can choose to do things like attach additional
 // information (such as stack traces) on calls to Error().
 //
-// # Verbosity
+// Verbosity
 //
 // Often we want to log information only when the application in "verbose
 // mode".  To write log lines that are more verbose, Logger has a V() method.
@@ -62,7 +62,7 @@ limitations under the License.
 // We can write:
 //   logger.V(2).Info("an unusual thing happened")
 //
-// # Logger Names
+// Logger Names
 //
 // Logger instances can have name strings so that all messages logged through
 // that instance have additional context.  For example, you might want to add
@@ -79,7 +79,7 @@ limitations under the License.
 // joining operation (e.g. whitespace, commas, periods, slashes, brackets,
 // quotes, etc).
 //
-// # Saved Values
+// Saved Values
 //
 // Logger instances can store any number of key/value pairs, which will be
 // logged alongside all messages logged through that instance.  For example,
@@ -97,7 +97,7 @@ limitations under the License.
 //   // later on...
 //   obj.logger.Info("setting foo", "value", targetValue)
 //
-// # Best Practices
+// Best Practices
 //
 // Logger has very few hard rules, with the goal that LogSink implementations
 // might have a lot of freedom to differentiate.  There are, however, some
@@ -112,7 +112,7 @@ limitations under the License.
 // may be any Go value, but how the value is formatted is determined by the
 // LogSink implementation.
 //
-// # Key Naming Conventions
+// Key Naming Conventions
 //
 // Keys are not strictly required to conform to any specification or regex, but
 // it is recommended that they:
@@ -129,22 +129,21 @@ limitations under the License.
 // While users are generally free to use key names of their choice, it's
 // generally best to avoid using the following keys, as they're frequently used
 // by implementations:
-//
-//   * "caller": the calling information (file/line) of a particular log line.
-//   * "error": the underlying error value in the `Error` method.
-//   * "level": the log level.
-//   * "logger": the name of the associated logger.
-//   * "msg": the log message.
+//   * "caller": the calling information (file/line) of a particular log line
+//   * "error": the underlying error value in the `Error` method
+//   * "level": the log level
+//   * "logger": the name of the associated logger
+//   * "msg": the log message
 //   * "stacktrace": the stack trace associated with a particular log line or
-//                   error (often from the `Error` message).
-//   * "ts": the timestamp for a log line.
+//                   error (often from the `Error` message)
+//   * "ts": the timestamp for a log line
 //
 // Implementations are encouraged to make use of these keys to represent the
 // above concepts, when necessary (for example, in a pure-JSON output form, it
 // would be necessary to represent at least message and timestamp as ordinary
 // named values).
 //
-// # Break Glass
+// Break Glass
 //
 // Implementations may choose to give callers access to the underlying
 // logging implementation.  The recommended pattern for this is:
@@ -477,3 +476,21 @@ type CallStackHelperLogSink interface {
 	// call site information.
 	GetCallStackHelper() func()
 }
+
+// Marshaler is an optional interface that logged values may choose to
+// implement. Loggers with structured output, such as JSON, should
+// log the object return by the MarshalLog method instead of the
+// original value.
+type Marshaler interface {
+	// MarshalLog can be used to:
+	//   - ensure that structs are not logged as strings when the original
+	//     value has a String method: return a different type without a
+	//     String method
+	//   - select which fields of a complex type should get logged:
+	//     return a simpler struct with fewer fields
+	//   - log unexported fields: return a different struct
+	//     with exported fields
+	//
+	// It may return any value of any type.
+	MarshalLog() interface{}
+}