cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Krüger (Updated) (JIRA) <j...@apache.org>
Subject [jira] [Updated] (CXF-4227) AttachmentDeserializerTest contains buggy code for reading an InputStream.
Date Wed, 04 Apr 2012 19:54:18 GMT

     [ https://issues.apache.org/jira/browse/CXF-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andreas Krüger updated CXF-4227:
--------------------------------

    Description: 
Browsing through the CXF code, I stumbled over the following in AttachmentDeserializerTest,
method testCXF3383():

{code}
for (int x = 1; x < 50; x++) {
    String cid = "1882f79d-e20a-4b36-a222-7a75518cf395-" + x + "@cxf.apache.org";
    DataSource ds = AttachmentUtil.getAttachmentDataSource(cid, message.getAttachments());
    byte bts[] = new byte[1024];
            
    InputStream ins = ds.getInputStream();
    int count = ins.read(bts, 0, bts.length);
    int sz = ins.read(bts, count, bts.length - count);
    while (sz != -1) {
        sz = ins.read(bts, count, bts.length - count);
    }
    assertEquals(x + 1, count);
}
{code}

I think some "count += sz" has been forgotten. Details:

* The while-loop does nothing to change the test result.
* Endless loop, should "ins" ever deliver 1025 bytes or more.
* (If "ins" is 0 bytes, then count will be -1.)
* The fix is obvious, I'll attach a patch.

The problem does not show as long as "ins" contains less than 1024 bytes and all its content
is delivered with the first read operation. So no functional impairment, just code hygiene.

  was:
Browsing through the CXF code, I stumbled over the following in AttachmentDeserializerTest,
method testCXF3383():

{code}
for (int x = 1; x < 50; x++) {
    String cid = "1882f79d-e20a-4b36-a222-7a75518cf395-" + x + "@cxf.apache.org";
    DataSource ds = AttachmentUtil.getAttachmentDataSource(cid, message.getAttachments());
    byte bts[] = new byte[1024];
            
    InputStream ins = ds.getInputStream();
    int count = ins.read(bts, 0, bts.length);
    int sz = ins.read(bts, count, bts.length - count);
    while (sz != -1) {
        sz = ins.read(bts, count, bts.length - count);
    }
    assertEquals(x + 1, count);
}
{code}

I think some "count += sz" has been forgotten. Details:

* The while-loop does nothing to change the test result.
* Endless loop, should "ins" ever deliver 1025 bytes or more.
* The fix is obvious, I'll attach a patch.

The problem does not show as long as "ins" contains less than 1024 bytes and all its content
is delivered with the first read operation. So no functional impairment, just code hygiene.

    
> AttachmentDeserializerTest contains buggy code for reading an InputStream.
> --------------------------------------------------------------------------
>
>                 Key: CXF-4227
>                 URL: https://issues.apache.org/jira/browse/CXF-4227
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>            Reporter: Andreas Krüger
>            Priority: Minor
>              Labels: patch
>         Attachments: AttachmentDeserializerTest.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Browsing through the CXF code, I stumbled over the following in AttachmentDeserializerTest,
method testCXF3383():
> {code}
> for (int x = 1; x < 50; x++) {
>     String cid = "1882f79d-e20a-4b36-a222-7a75518cf395-" + x + "@cxf.apache.org";
>     DataSource ds = AttachmentUtil.getAttachmentDataSource(cid, message.getAttachments());
>     byte bts[] = new byte[1024];
>             
>     InputStream ins = ds.getInputStream();
>     int count = ins.read(bts, 0, bts.length);
>     int sz = ins.read(bts, count, bts.length - count);
>     while (sz != -1) {
>         sz = ins.read(bts, count, bts.length - count);
>     }
>     assertEquals(x + 1, count);
> }
> {code}
> I think some "count += sz" has been forgotten. Details:
> * The while-loop does nothing to change the test result.
> * Endless loop, should "ins" ever deliver 1025 bytes or more.
> * (If "ins" is 0 bytes, then count will be -1.)
> * The fix is obvious, I'll attach a patch.
> The problem does not show as long as "ins" contains less than 1024 bytes and all its
content is delivered with the first read operation. So no functional impairment, just code
hygiene.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message