commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ronan KERDUDOU - VirageGroup" ...@viragegroup.com>
Subject RE: [VFS] MonitorInputStream doesn't correctly support 'mark'
Date Tue, 23 Feb 2010 00:32:50 GMT
Created VFS-301 : https://issues.apache.org/jira/browse/VFS-301

I don't have patch to give, just a poor workaround. I don't know enough of
VFS to modify a core file without potentially damaging the product.

Regards,
Kerdudou Ronan

-----Message d'origine-----
De : Ralph Goers [mailto:ralph.goers@dslextreme.com]
Envoyé : samedi 20 février 2010 17:07
À : Commons Developers List
Objet : Re: [VFS] MonitorInputStream doesn't correctly support 'mark'

It would be great if you could open a Jira issue for this with the
explanation below. It would also be great if you could provide a patch to
fix the problem.

Ralph

On Feb 20, 2010, at 6:37 AM, Ronan KERDUDOU - VirageGroup wrote:

> Hi,
>
>
>
> Here is a serious issue in the
> org.apache.commons.vfs.util.MonitorInputStream (and so it is also in
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentInputStream)
>
>
>
> FileContentInputStream extends MonitorInputStream extends
> BufferedInputStream
>
> So they support < mark > (stream.markSupported() returns true)
>
>
>
> But in MonitorInputStream.read(), when reaching the end of the stream,
there
> is a call to close() regardless if 'mark' is positioned.
>
> To respect BufferedInputStream specifications we shouldn't close the
stream
> in order to be able to call reset() on the stream and return in the state
i
> twas when we called mark().
>
>
>
> Usually doing the folowing before using mark feature :
>
>        if (!stream.markSupported()) {
>
>            stream = new BufferedInputStream(stream);
>
>        }
>
> Won't work with a VFS stream.
>
>
>
> So what i did :
>
>        if (!stream.markSupported() || stream instanaceof
> MonitorInputStream) { //Hack to solve a VFS issue
>
>            stream = new BufferedInputStream(stream);
>
>        }
>
>
>
> I inform you also that in the BufferedInputStream.close() doc, it'written
:
>
> < Once the stream has been closed, further read(), available(), reset(),
or
> skip() invocations will throw an IOException. >
>
> And in the MonitorInputStream, if we call read() after close() it returns
> '-1'.
>
>
>
> Thank you in advance for solving this issue (may be somewhat difficult not
> to break compatibility with code that uses this specific usage)
>
>
>
> IMHO,
>
> I think < end-of-stream monitoring > doesn't mean < close when reach the
end
>> but should mean < propose a way to execute some code when reaching the
end
>> but anyway if we put a call to close() in this code it breaks the
> habillity to call reset().
>
> As this class consequently modify the comportment from the super class it
> should be more documented and explain what it does.
>
> I would say that your class is currently doing end-of-stream autoClose and
> after-close monitoring.
>
> Maybe it shouldn't extends BufferedInputStream to avoid confusion and
don't
> try to support 'mark' (respond false in markSupported()) as it doesn't
seem
> to serve you.
>
>
>
> Regards,
>
>
>
> KERDUDOU Ronan
>
> VIRAGE Group (France)
>
> +33 2 53 55 10 22
>
> rk@viragegroup.com
>
> www.viragegroup.com <http://www.viragegroup.com/>
>
>
>
>
>





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message