Daniel,
2. would be great. I don't know if other code maybe suffer from
not flushing the stream. Normally the caller is reponsible for
flushing and closing the OutputStream.
In my current case flushing _at the end_ would be no harm. But
it could harm if I'd like to stream direct to ServletOutput.
I don't really know what my colleagues will call this FTPUtil class
with. But I can write a workaround that is copying the stream
itself.
Maybe there can be an optional setting not to flush the stream?
However, a note that retrieveFile flushes the stream should be in
the javadoc comment of this method.
Daniel F. Savarese wrote:
>
> In message <413C7ACC.3070207@picturesafe.de>, Marco Jacob writes:
>
>> FTPClient.retrieveFile(String, OutputStream)
>>
>>flushes the OutputStream after each time it calls write(byte[], int, int)=
>>=2E
>
> ...
>
>>I think, FTPClient.retrieveFile(String, OutputStream) should never flush
>>or close() the given OutputStream. The calling method should do this.
>>
>>However, can this be changed in the next release?
>
>
> There are three separate issues here. The first two concern the flush
> issue and the third the close issue.
>
> 1. retrieveFile calls Util.copyStream as a convenience. So it's not
> retrieveFile that is doing the flushing. It's a byproduct of the call.
> Should retrieveFile call Util.copyStream? Probably, because otherwise
> we'd just have to write another stream copying utility function.
>
> 2. Util.copyStream flushes the output stream after every write. Does it
> have to do this? It doesn't have to do this for retrieveFile, but
> it does have to do it to support interactive sessions for other
> protocols like telnet which would hang because java.io classes would
> hold onto their buffers. At the very least, it's a holdover from
> JDK 1.1 days when the call to flush was the only way to make some things
> work. Since not every caller of copyStream needs the flushing, an option
> can be provided to disable it. We can leave flushing as the default
> to avoid breaking anything and add a new method with an extra argument
> turning flushing on or off (the original method would call it with
> flushing on). FTPClient can then use this method with flushing turned
> off. However, the underlying OutputStream may wind up making its own
> flush calls inside of write, so this may not completely resolve your
> particular situation.
>
> 3. Should retrieveFile close the output stream? No. In fact, it does not.
> Only the source is closed, which has to be done anyway because the
> end of stream is reached.
>
> Historical note. I didn't want there to be a retrieveFile or a storeFile
> method because I thought convenience methods should go into subclasses or
> wrappers. retrieveFileStream and storeFileStream already provided the
> required primitive functionality. But users really wanted retrieveFile
> and storeFile in FTPClient, so there you go.
>
> Anyway, if you think the solution in 2. is useful, we can make the
> appropriate adjustments. However, I have dim memory that there may
> be an issue with not flushing in storeFile. We can put in flush
> before the close there just in case. I think some java.io classes
> in JDK 1.1 days may not have flushed buffered output on closing and
> there may have been incomplete data written.
>
> daniel
--
Marco Jacob
picturesafe GmbH
Software Development
Lüerstraße 3
D-30175 Hannover
GERMANY
Fon: +49 511 - 856 20 54
Fax: +49 511 - 856 20 10
mailto:mjacob@picturesafe.de
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
|