cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "aaron pieper (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CXF-2050) MimeBodyPartInputStream never finishes reading certain streams
Date Wed, 18 Feb 2009 18:16:01 GMT

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

aaron pieper updated CXF-2050:
------------------------------

    Attachment: MimeBodyPartInputStreamTest.java

Here is a test case which duplicates the issue. Executing this test case will demonstrate
that MimeBodyInputStream.read() is returning 0 over and over.

Alternatively, you can change this test so that it calls IOUtils.toString() on the stream.
This will cause the code to enter an infinite loop, similar to the behavior caused by AttachmentDeserializer.

> MimeBodyPartInputStream never finishes reading certain streams
> --------------------------------------------------------------
>
>                 Key: CXF-2050
>                 URL: https://issues.apache.org/jira/browse/CXF-2050
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.1.4
>            Reporter: aaron pieper
>         Attachments: MimeBodyPartInputStreamTest.java
>
>
> The MimeBodyPartInputStream class never finishes reading certain kinds of input streams
- it continues to read the same bytes over and over. One result of this issue is that the
AttachmentDeserializer enters an infinite loop when trying to deserialize a binary attachment,
so I would consider this an important issue.
> It appears that the problem has to do with how the end of the stream is read. First,
the MimeBody stream's read() method reads the to the end of the PushBack stream. Upon reaching
the end of the PushBack stream, the MimeBody stream's hasData() method unreads the last 15
bytes of the PushBack stream. The MimeBody stream's read() method returns 0, which signals
that more data needs to be read. This loop can happen over and over - the invoking code will
keep asking the MimeBody stream for more data, and the MimeBody stream will continue returning
0.
> The MimeBody stream should return -1 if there is no more data to be read - it does this
in most cases, but it doesn't handle this case for some reason.

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


Mime
View raw message