commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Otto Fowler (JIRA)" <>
Subject [jira] [Commented] (VFS-301) MonitorInputStream doesn't correctly support 'mark'
Date Sat, 24 Feb 2018 13:55:00 GMT


Otto Fowler commented on VFS-301:

VFS-614 has a PR

> MonitorInputStream doesn't correctly support 'mark'
> ---------------------------------------------------
>                 Key: VFS-301
>                 URL:
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0, 2.0
>            Reporter: Ronan KERDUDOU
>            Priority: Major
>   Original Estimate: 6h
>  Remaining Estimate: 6h
> Message I posted on the mailing list on Sat, 20 Feb, 14:37 (dev-118064)
> and Ralph Goers answered to create a jira (dev-118068 )
> 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, 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 it was when we called mark().
> Usually doing the folowing before using mark feature :
> {code}
> if (!stream.markSupported()) {
>     stream = new BufferedInputStream(stream);
> }
> {code}
> Won't work with a VFS stream.
> So what i did :
> {code}
> if (!stream.markSupported() || stream instanceof MonitorInputStream) { //Hack to solve
a VFS issue
>     stream = new BufferedInputStream(stream);
> }
> {code}
> 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)
> 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 this class is currently doing "end-of-stream autoClose and after-close
> 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 internally in VFS Project.
(Can a power-developer of VFS confirm it ?)
> Regards,

This message was sent by Atlassian JIRA

View raw message