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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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
