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 12:50:45 UTC

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

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


Summary:

The JMSObjectMessage toBodyString calls toString(ByteBuffer b). This method assumes that the Object Message can be converted to a string using:
            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 getObject() will result in an EOFException as the full buffer is unable to be read due to the limit point change.


Steps to Reproduce:
Send a java object and print the message S.o.pln(message); before you call getObject().

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.

Proposed Changes:
Remove the toString(ByteBuffer b) method and change the toBodyString to perform:

String.valueOf(getObject());

This will ensure that the toString will work as long as getObject() can be continually called.

Test Strategy:
To test we should create an additional test in ObjectMessageTest

testToString()

//Setup
//Receive Message
ObjectMessage message=client.receive();

//Test
String messageAsString = message.toString();

Object objectAfterToString = message.getObject();
// catch and fail all errors
AssertNotNull("Error Object not received after toString",objectAfterToString );

//Perform the toBodyString Explicitly
String messageBodyAsString = message.toBodyString();

Object objectAfterToBodyString = message.getObject();
// catch and fail all errors
AssertNotNull("Error Object not received after toBodyString",objectAfterToBodyString );


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/QPID-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601971#action_12601971 ] 

Martin Ritchie commented on QPID-1117:
--------------------------------------

Test committed to M2.x & Merged to M2.1.x 

Trunk merge still pending.

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


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

Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aidan Skinner resolved QPID-1117.
---------------------------------

    Resolution: Fixed

Merged this to trunk

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


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

Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
    [ 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.


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

Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Ritchie updated QPID-1117:
---------------------------------

           Description: 
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.


  was:
Summary:

The JMSObjectMessage toBodyString calls toString(ByteBuffer b). This method assumes that the Object Message can be converted to a string using:
            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 getObject() will result in an EOFException as the full buffer is unable to be read due to the limit point change.


Steps to Reproduce:
Send a java object and print the message S.o.pln(message); before you call getObject().

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.

Proposed Changes:
Remove the toString(ByteBuffer b) method and change the toBodyString to perform:

String.valueOf(getObject());

This will ensure that the toString will work as long as getObject() can be continually called.

Test Strategy:
To test we should create an additional test in ObjectMessageTest

testToString()

//Setup
//Receive Message
ObjectMessage message=client.receive();

//Test
String messageAsString = message.toString();

Object objectAfterToString = message.getObject();
// catch and fail all errors
AssertNotNull("Error Object not received after toString",objectAfterToString );

//Perform the toBodyString Explicitly
String messageBodyAsString = message.toBodyString();

Object objectAfterToBodyString = message.getObject();
// catch and fail all errors
AssertNotNull("Error Object not received after toBodyString",objectAfterToBodyString );


    Remaining Estimate: 2h  (was: 1h)
     Original Estimate: 2h  (was: 1h)

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