Feature request: ability to suppress logging of message fields

42 views
Skip to first unread message

Robert H

unread,
Feb 17, 2011, 7:10:03 PM2/17/11
to Protocol Buffers
If you use protobuf for confidential data, enabling debugt logging
exposes the data. It would be nice to have a field option that directs
the TextFormat class to not log a field.

TJ Rothwell

unread,
Feb 17, 2011, 7:25:22 PM2/17/11
to Robert H, Protocol Buffers
I have a similar need but haven't looked into a solution. However, would using "bytes" instead of "string" prevent the output? Or does the debug logging also output the contents of the bytes?

-- TJ


--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.


Kenton Varda

unread,
Feb 22, 2011, 1:38:33 PM2/22/11
to Robert H, Protocol Buffers
You can always write custom code that formats messages any way you want for your logs.  The TextFormat class is based purely on public interfaces, so you can copy it and modify it.  You can define a custom option for flagging fields that you want removed from the logs and use that custom option in your modified TextFormat.

I don't think we want to implement this feature directly in the base implementation.  There are too many little feature requests like this, and if we implemented them all the library would get quite bloated.

Robert H

unread,
Feb 22, 2011, 6:14:13 PM2/22/11
to Protocol Buffers
That makes perfect sense.

Yes, of course I know I can implement my own method to log messages,
and, in fact, that's what I'm doing. It would be nice if TextFormat
were written in such a way that I didn't have to copy the code. In
fact, if my logger is debug enabled, I construct a
java.lang.reflect.Proxy for the Message the delegates getAllFields,
but replaces the fields I want to suppress. It's a little hacky, but
it is the only way to take advantage of TextFormat without copying the
code. I want to avoid copying because who knows what you'll do on the
next version?

Anyway, thanks for considering it. And thanks for keeping protobuf
bloat-free!

TJ Rothwell

unread,
Feb 28, 2011, 5:48:07 PM2/28/11
to Protocol Buffers
Kenton,

I have a message that contains fields that should never be logged. It would be great if there was a way that the Message.toString() did not automatically convert everything to a text representation. I'd love it if it were an opt-in for the TextFormat instead of trying never to use toString() on those messages.

Since AbstractMessage.toString() currently calls the static method for TextFormat, would it be too much bloat to have an SPI layer there to attach a custom formatter? Or maybe just not have a toString() at all where everyone must explicitly use TextFormat.

The extra conditional isn't a problem--it's the fact that somewhere in the code there may be a string cast where the field may be converted is bad or in new code from a developer that isn't aware that toString() will behave that way.

Message myMessage;
log.debug("message={}", myMessage); // TextFormat.printToString()
if(log.isDebugEnabled()) {
  log.debug("message={}", MyTextFormat.printToString(myMessage));
}

Thanks,
-- TJ




--
Reply all
Reply to author
Forward
0 new messages