[
https://issues.apache.org/jira/browse/AMQ-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310536#comment-17310536
]
Gary Tully commented on AMQ-8209:
---------------------------------
good catch, that code was intentionally duplicated from aries[1] such that the
logs with xid's would match between the transaction manager and the resource
and it would be possible to correlate the two through logging.
however our default string rep, should be correct and needs a fix, the aries
match should be confined to an aries format id [2].
[1]
https://github.com/apache/geronimo-txmanager/blob/e9291012b3605fd45cbd34e7b3a4057a385d64be/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/XidImpl.java
[2]
https://github.com/apache/geronimo-txmanager/blob/e9291012b3605fd45cbd34e7b3a4057a385d64be/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/XidImpl.java#L30
It also looks like the use of getTransactionKey in the compareTo needs are
revisit.
> 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
> Priority: Major
>
> {{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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
