You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org> on 2008/06/03 17:06:44 UTC

[jira] Commented: (QPID-1117) AbstractBytesMessage.getText corrupts the ByteBuffer if the data is not a String

    [ 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.