[
https://issues.apache.org/jira/browse/AMQ-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcono1234 updated AMQ-8209:
-----------------------------
Description:
{{org.apache.activemq.command.XATransactionId.stringFormDefault(...)}} creates
malformed hex strings:
{code}
private void stringFormDefault(StringBuffer s, byte[] uid) {
for (int i = 0; i < uid.length; i++) {
s.append(Integer.toHexString(uid[i]));
}
}
{code}
There are two flaws with this:
- It uses the signed byte value, so for {{(byte) 0xFF}},
{{Integer.toHexString(...)}} will be {{ffffffff}}.
- It does not check the length of the {{toHexString}} result; for values < 16
it will only emit one hex char, so both {{1, 0}} and {{16}} will have the hex
string {{10}}.
For example:
{code}
StringBuffer sb = new StringBuffer();
stringFormDefault(sb, new byte[] {1, 0, 16, -1});
System.out.println(sb.toString());
// Expected: 010010ff
// Actual: 1010ffffffff
{code}
If this behavior is intended (e.g. because a different project relies on this
broken hex string format), then it would at least be good to add a comment
explaining this.
This is the case since commit
[101e7110bcd768fd8f08df063fcd4ef16f77f033|https://github.com/apache/activemq/commit/101e7110bcd768fd8f08df063fcd4ef16f77f033#diff-a0c2a713c0431714bf597657f5e1386d8f7ced5bb2aadc25b4a54be00a40bf84L53-R59].
Note that you could probably fix this by using
{{org.apache.activemq.util.HexSupport}} again, though I am not sure if that
would break backward compatibility now.
was:
{{org.apache.activemq.command.XATransactionId.stringFormDefault(...)}} creates
malformed hex strings:
{code}
private void stringFormDefault(StringBuffer s, byte[] uid) {
for (int i = 0; i < uid.length; i++) {
s.append(Integer.toHexString(uid[i]));
}
}
{code}
There are two flaws with this:
- It uses the signed byte value, so for {{(byte) 0xFF}},
{{Integer.toHexString(...)}} will be {{ffffffff}}.
- It does not check the length of the {{toHexString}} result; for values < 16
it will only emit one hex char, so both {{1, 0}} and {{16}} will have the hex
string {{10}}.
For example:
{code}
StringBuffer sb = new StringBuffer();
stringFormDefault(sb, new byte[] {1, 0, 16, -1});
System.out.println(sb.toString());
// Expected: 010001ff
// Actual: 1010ffffffff
{code}
If this behavior is intended (e.g. because a different project relies on this
broken hex string format), then it would at least be good to add a comment
explaining this.
This is the case since commit
[101e7110bcd768fd8f08df063fcd4ef16f77f033|https://github.com/apache/activemq/commit/101e7110bcd768fd8f08df063fcd4ef16f77f033#diff-a0c2a713c0431714bf597657f5e1386d8f7ced5bb2aadc25b4a54be00a40bf84L53-R59].
Note that you could probably fix this by using
{{org.apache.activemq.util.HexSupport}} again, though I am not sure if that
would break backward compatibility now.
> XATransactionId.stringFormDefault(...) creates malformed hex strings
> --------------------------------------------------------------------
>
> Key: AMQ-8209
> URL: https://issues.apache.org/jira/browse/AMQ-8209
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.16.1
> Reporter: Marcono1234
> Assignee: Jean-Baptiste Onofré
> Priority: Major
> Fix For: 5.17.0, 5.16.4
>
>
> {{org.apache.activemq.command.XATransactionId.stringFormDefault(...)}}
> creates malformed hex strings:
> {code}
> private void stringFormDefault(StringBuffer s, byte[] uid) {
> for (int i = 0; i < uid.length; i++) {
> s.append(Integer.toHexString(uid[i]));
> }
> }
> {code}
> There are two flaws with this:
> - It uses the signed byte value, so for {{(byte) 0xFF}},
> {{Integer.toHexString(...)}} will be {{ffffffff}}.
> - It does not check the length of the {{toHexString}} result; for values < 16
> it will only emit one hex char, so both {{1, 0}} and {{16}} will have the hex
> string {{10}}.
> For example:
> {code}
> StringBuffer sb = new StringBuffer();
> stringFormDefault(sb, new byte[] {1, 0, 16, -1});
> System.out.println(sb.toString());
> // Expected: 010010ff
> // Actual: 1010ffffffff
> {code}
> If this behavior is intended (e.g. because a different project relies on this
> broken hex string format), then it would at least be good to add a comment
> explaining this.
> This is the case since commit
> [101e7110bcd768fd8f08df063fcd4ef16f77f033|https://github.com/apache/activemq/commit/101e7110bcd768fd8f08df063fcd4ef16f77f033#diff-a0c2a713c0431714bf597657f5e1386d8f7ced5bb2aadc25b4a54be00a40bf84L53-R59].
> Note that you could probably fix this by using
> {{org.apache.activemq.util.HexSupport}} again, though I am not sure if that
> would break backward compatibility now.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
