axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 9780] New: - Attachments Error serializing DataHandlers that are not backed by FileDataSource
Date Tue, 11 Jun 2002 14:29:42 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9780>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9780

Attachments Error serializing DataHandlers that are not backed by FileDataSource

           Summary: Attachments Error serializing DataHandlers that are not
                    backed by FileDataSource
           Product: Axis
           Version: beta-2
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Serialization/Deserialization
        AssignedTo: axis-dev@xml.apache.org
        ReportedBy: jason.blumenkrantz@tfn.com


org.apache.axis.attachments.MimeUtils.getContentLength() will read (and 
therefore invalidate) an Input Stream to determine the content length of 
attached content, if the DataHandler is not backed by a FileDataSource. 
Therefore, when I return a "dynamic" InputStream that is not backed by a file 
or a byte array, no data is getting written in the MIME body part, since the 
stream was read fully in determining the correct length. 

What I've done as a workaround is to have my InputStream return an "empty"
byte array input stream the first time getInputStream() is called (used to
count the content length) and then return the real stream for subsequent
calls. I've then overridden AxisServlet to not output the content length
(since I figure it's better for it not to be present than to be downright
wrong). 

Possible solutions (many are partial solutions):
1. Have MimeUtils check if the underlying stream is a ByteArrayInputStream
so that MimeUtils can determine the length from the bytes and not from
rereading the stream.
2. Allow web service developers to use an extended (Axis-specific)
"SizedDataSource" for their DataHandler, with an additional "getSize()"
method that can be used to determine the content length.
3. Allow the developer to specify via a global configuration property that the 
content length should not be returned, so it need not be determined (which is 
along the lines of what I'm doing now, although this doesn't work for all 
servlet engines)
4. For those servlet engines where the content length is required, read the
stream fully to determine the length, but keep the data cached in memory so 
that it does not have to be read a second time. This is inefficient, but given 
the first three options hopefully this can be avoided.

I'd be willing to help implement these fixes if there was a consensus as to the 
best way to fix this bug.

-Jason

Mime
View raw message