[
https://issues.apache.org/jira/browse/ZOOKEEPER-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974179#comment-15974179
]
Brandon Berg edited comment on ZOOKEEPER-2763 at 4/19/17 6:50 AM:
------------------------------------------------------------------
This also appears to be broken for any bytes with negative value, in which case
it prints the full eight-digit int equivalent. For example, the byte array
\{0x10, 0x05, -0x20\} serializes to #105ffffffe0
was (Author: bberg):
This also appears to be broken for any bytes with negative value, in which case
it prints the full eight-digit int equivalent. For example, the byte array
{0x10, 0x05, -0x20} serializes to #105ffffffe0
> Utils.toCsvBuffer() omits leading 0 for bytes < 0x10
> ----------------------------------------------------
>
> Key: ZOOKEEPER-2763
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2763
> Project: ZooKeeper
> Issue Type: Bug
> Components: jute
> Affects Versions: 3.5.2
> Reporter: Brandon Berg
> Priority: Minor
>
> org.apache.jute.Utils.toCsvBuffer(), which converts a byte array to a string
> containing the hex representation of that byte array, omits the leading zero
> for any byte less than 0x10, due to its use of Integer.toHexString, which has
> the same behavior.
> https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/jute/Utils.java#L234
> One consequence of this is that the hex strings printed by
> ClientCnxn.Packet.toString(), used in the debug logging for
> ClientCnxn.readResponse(), cannot be parsed to determine the result of a
> Zookeeper request from client debug logs.
> Utils.toXmlBuffer() appears to have the same issue.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
