[
https://issues.apache.org/jira/browse/QPID-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601968#action_12601968
]
Martin Ritchie commented on QPID-1117:
--------------------------------------
This is not an issue.
Only the ObjectMessage writes directly in to the ByteBuffer, which can cause
problems as seen in QPID-1092.
All other instances have a value at the start of the ByteBuffer that can be
interpreted as a String. So corruption by using a toString won't occur.
To ensure this is always the case a test for each Message type has been added
to the MessageToStringTest
> AbstractBytesMessage.getText corrupts the ByteBuffer if the data is not a
> String
> --------------------------------------------------------------------------------
>
> Key: QPID-1117
> URL: https://issues.apache.org/jira/browse/QPID-1117
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M2, M2.1
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M3
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Summary:
> The AbstractBytesMessage.toBodyString calls getText(). This method attempts
> to extract the data in the buffer as a String.
> return data.getString(Charset.forName("UTF8").newDecoder());
> However, if this fails then the byte buffer limit value is set to the last
> byte read by the decoder.
> Subsequent calls to that use the buffer will will result in an EOFException
> as the full buffer is unable to be read due to the limit point change.
> Defect Identification:
> The current position in the buffer is recorded but the limit is not.
> Recording and resetting the limit would be one possible approach.
> Test Strategy:
> To test we should create additional tests against all subclasses of
> AbstractBytesMessage.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
