Closed panchenko closed 2 weeks ago
Disclaimer: I am just another user of protobuf and cannot influence the direction of the project.
One possible reason for why the proposed customization might be difficult to implement in a backward compatible way is that there may be code around that expects that the output of <T extends Message>.toString()
may be parsed back into an instance of T
via TextFormat.parse
. Having said that, I would appreciate if there was a supported way of suppressing the multi-line log output. There are many situations where single-line text logs are preferable, and protobuf messages make the output unreadable.
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.
This issue is labeled inactive
because the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.
This issue was closed and archived because there has been no new activity in the 14 days since the inactive
label was added.
What language does this apply to? java runtime library
Describe the problem you are trying to solve.
It's a common practice to log java objects, however in case of protobuf-generated classes toString() output is very long and multiline, see also #13576.
Describe the solution you'd like
If removing
final
from the method in the base class then in the generated classes a custom toString() implementation could be provided. Most of the time I would rather useshortDebugString()
there, but in the special cases a manually provided implementation would be more appropriate.Describe alternatives you've considered
Wrap objects with some function in every logging call, but that results in quite verbose code and has runtime costs.
Additional context
For example it's not final in ScalaPB, see https://github.com/scalapb/ScalaPB/issues/235