You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Boris Petrov <bo...@profuzdigital.com> on 2016/06/13 15:40:24 UTC

[vfs] Why does the MonitorInputStream close the stream in read?

I am using Apache Tika to detect file types. Somewhere in the code it does:

if (stream.markSupported())

Which returns "true" for a MonitorInputStream. Then it does:

stream.mark(...);
try {
    ... read(stream);
} finally {
    stream.reset();
}

Which should not be an issue as it already asked whether marking is
supported. However, due to "read" of MonitorInputStream closing the
stream, "reset" throws a "java.io.IOException: Stream closed". This is
obviously not good. Any ideas what I should do?

Thanks!


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


Re: [vfs] Why does the MonitorInputStream close the stream in read?

Posted by Boris Petrov <bo...@profuzdigital.com>.
Hi,

I've created an issue:

https://issues.apache.org/jira/browse/VFS-614

I hope it gets resolved soon and a new version is released as it is
quite horrible. :)

Thanks,

Boris


On 06/13/2016 10:20 PM, Bernd Eckenfels wrote:
> Hello Boris,
>
> I was not looking into the code, but from your description this sounds
> like something I would classify as a bug.
>
> Can you open a VFS issue for it please. Ideally with a reproducer unit
> test (w/o tika dependency).
>
> As a workaround I can imagine Tika has a markable wrapper already, so
> it can check for "(stream.markSupported() && !stream instanceof
> MonitorInputStream)...?
>
> Gruss
> Bernd
>
>  Am Mon, 13 Jun 2016 18:40:24
> +0300 schrieb Boris Petrov <bo...@profuzdigital.com>:
>
>> I am using Apache Tika to detect file types. Somewhere in the code it
>> does:
>>
>> if (stream.markSupported())
>>
>> Which returns "true" for a MonitorInputStream. Then it does:
>>
>> stream.mark(...);
>> try {
>>     ... read(stream);
>> } finally {
>>     stream.reset();
>> }
>>
>> Which should not be an issue as it already asked whether marking is
>> supported. However, due to "read" of MonitorInputStream closing the
>> stream, "reset" throws a "java.io.IOException: Stream closed". This is
>> obviously not good. Any ideas what I should do?
>>
>> Thanks!
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>


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


Re: [vfs] Why does the MonitorInputStream close the stream in read?

Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello Boris,

I was not looking into the code, but from your description this sounds
like something I would classify as a bug.

Can you open a VFS issue for it please. Ideally with a reproducer unit
test (w/o tika dependency).

As a workaround I can imagine Tika has a markable wrapper already, so
it can check for "(stream.markSupported() && !stream instanceof
MonitorInputStream)...?

Gruss
Bernd

 Am Mon, 13 Jun 2016 18:40:24
+0300 schrieb Boris Petrov <bo...@profuzdigital.com>:

> I am using Apache Tika to detect file types. Somewhere in the code it
> does:
> 
> if (stream.markSupported())
> 
> Which returns "true" for a MonitorInputStream. Then it does:
> 
> stream.mark(...);
> try {
>     ... read(stream);
> } finally {
>     stream.reset();
> }
> 
> Which should not be an issue as it already asked whether marking is
> supported. However, due to "read" of MonitorInputStream closing the
> stream, "reset" throws a "java.io.IOException: Stream closed". This is
> obviously not good. Any ideas what I should do?
> 
> Thanks!
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
> 


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