You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Ronan KERDUDOU (JIRA)" <ji...@apache.org> on 2010/02/23 00:32:28 UTC

[jira] Created: (VFS-301) MonitorInputStream doesn't correctly support 'mark'

MonitorInputStream doesn't correctly support 'mark'
---------------------------------------------------

                 Key: VFS-301
                 URL: https://issues.apache.org/jira/browse/VFS-301
             Project: Commons VFS
          Issue Type: Bug
    Affects Versions: 1.0, 1.1
            Reporter: Ronan KERDUDOU


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 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 it was 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 this 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 internally in VFS Project. (Can a power-developer of VFS confirm it ?)

Regards,
KERDUDOU Ronan


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (VFS-301) MonitorInputStream doesn't correctly support 'mark'

Posted by "Ronan KERDUDOU (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/VFS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ronan KERDUDOU updated VFS-301:
-------------------------------

    Affects Version/s: 2.0

> MonitorInputStream doesn't correctly support 'mark'
> ---------------------------------------------------
>
>                 Key: VFS-301
>                 URL: https://issues.apache.org/jira/browse/VFS-301
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0, 1.1, 2.0
>            Reporter: Ronan KERDUDOU
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> 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 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 it was 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 this 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 internally in VFS Project. (Can a power-developer of VFS confirm it ?)
> Regards,
> KERDUDOU Ronan

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (VFS-301) MonitorInputStream doesn't correctly support 'mark'

Posted by "Ronan KERDUDOU (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/VFS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837004#action_12837004 ] 

Ronan KERDUDOU commented on VFS-301:
------------------------------------

Quick link to File concerned :
http://svn.apache.org/repos/asf/commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/util/MonitorInputStream.java



> MonitorInputStream doesn't correctly support 'mark'
> ---------------------------------------------------
>
>                 Key: VFS-301
>                 URL: https://issues.apache.org/jira/browse/VFS-301
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0, 1.1
>            Reporter: Ronan KERDUDOU
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> 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 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 it was 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 this 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 internally in VFS Project. (Can a power-developer of VFS confirm it ?)
> Regards,
> KERDUDOU Ronan

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.