[
https://issues.apache.org/jira/browse/ZOOKEEPER-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976134#comment-15976134
]
Brandon Berg commented on ZOOKEEPER-2763:
-----------------------------------------
I just noticed that this is a duplicate of ZOOKEEPER-1716. There's a
better-performing fix suggested there, but it seems the assignee abandoned it
over a year ago after causing some unit tests to fail (possibly because the
unit tests were expecting the wrong result, but I don't know because the test
results have long since been deleted). I would suggest using that fix (the
NIBBLE_TO_HEX one, not the String.format one) instead of mine. Note also that
the initial allocation of the StringBuffer is incorrect. The size should be 2 *
barr.length + 1, not barr.length + 1. This is fine functionally, but leads to
and unnecessary reallocation when the initial buffer is full.
You could make a generic version of the function that takes a "prefix" String
argument, like:
{code}
private static String toHexString(String prefix, byte[] barr) {
if (barr == null || barr.length == 0) {
return ""; // Or should it return the prefix? Current behavior is not
to, but we've already identified multiple problems with the current behavior.
}
StringBuilder sb = new StringBuilder(2 * barr.length + prefix.length());
sb.append(prefix);
for(int idx = 0; idx < barr.length; idx++) {
byte b = barr[idx];
sb.append(NIBBLE_TO_HEX[b&0x0f]);
sb.append(NIBBLE_TO_HEX[(b&0xf0)>>4]);
}
return sb.toString();
}
public static String toCSVBuffer(byte[] barr) {
return toHexString("#", barr);
}
public static String toXMLBuffer(byte[] barr) {
return toHexString("", barr);
}
{code}
Also, it may be better to close this bug as duplicate and submit a fix for the
original bug. I don't really know what the procedure is. [~chelin], are you
still around? Do you remember what happened with ZOOKEEPER-1716?
> 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
> Assignee: Alburt Hoffman
> 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)
