RE: beta2 attachments bug?

["Blumenkrantz, Jason" <Ja...@tfn.com>]

Bob-
I've had the same experience with attachment handlings in Axis, I've posted
about it before and haven't found a solution to date. This happens because
MIMEUtils is reading the entire stream to determine the content length for
the response, if the DataSource is not a FileDataSource.

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

As far as fixing the underlying problem, I'd like to see a few things
happen:
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 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 to determine the length, but keep the data 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.

Does any of these sound feasible?
-Jason


-----Original Message-----
From: Robert Herold [mailto:herold@cotagesoft.com]
Sent: Monday, May 20, 2002 8:22 PM
To: axis-user@xml.apache.org
Subject: beta2 attachments bug?


In Beta2, the attachment handling reads the attachment input stream twice!
While this works OK for files, it will not work for data sources that are
true streams.  It also seems inefficient.

I found this out because I want to send some data as an attachment.  I tried
out the attachments sample, and it worked.  Then I replaced the
FileDataSource with my own DataSource, which always handed back the same
InputStream in getInputStream().  Peeking at the traffic with TCPMon, no
data was transmitted in the attachment part (because the stream was
exhausted by being read already).

Whittling it down to a simple String datasource and changing
getInputStream() to always hand back a new stream (and the debug message)
revealed what was going on:

  private class XStringDataSource implements DataSource {
      private String str = null;
	// private InputStream is = null;

      public XStringDataSource(String s) {
	  this.str = s;
        //this.is = (InputStream) new ByteArrayInputStream(str.getBytes());
      }

      public String getContentType() {
        return "application/octet-stream";
      }

      public InputStream getInputStream() {
        System.out.println("in getInputStream");
        // return is;
        return (InputStream) new ByteArrayInputStream(str.getBytes());
      }

      public String getName() {
        return "My String InputStream Data Source";
      }

      public OutputStream getOutputStream() throws IOException {
        throw new IOException("OutputStream not supported");
      }
    }

and in the code that sends the attachments:

  DataHandler dhSource = new DataHandler( new XStringDataSource( "Rufus T.
Firefly" ));

Is it the correct behavior for Axis to ask for and read the input stream
twice?

-- bob

----------
Robert Herold
Cotagesoft, Inc.