You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2011/05/18 21:16:49 UTC
[jira] [Resolved] (TIKA-645) Parsers can't get at an underlying
TikaInputStream to get the file if they wanted one
[ https://issues.apache.org/jira/browse/TIKA-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting resolved TIKA-645.
--------------------------------
Resolution: Fixed
Fix Version/s: 1.0
Assignee: Jukka Zitting
And in revision 1124385 I modified SecureContentHandler to use TikaInputStream instead of CountingInputStream, which avoids the other stream wrapper.
Now a TikaInputStream given to AutoDetectParser will get passed as-is all the way down to the concrete Parser implementation, so I'm resolving this as fixed.
Note that this fix required a minor backwards-compatibility break in the SecureContentHandler class, but this shouldn't be a big issue since I don't think the class is widely used outside AutoDetectParser.
> Parsers can't get at an underlying TikaInputStream to get the file if they wanted one
> -------------------------------------------------------------------------------------
>
> Key: TIKA-645
> URL: https://issues.apache.org/jira/browse/TIKA-645
> Project: Tika
> Issue Type: Bug
> Components: parser
> Affects Versions: 0.9
> Reporter: Nick Burch
> Assignee: Jukka Zitting
> Fix For: 1.0
>
>
> Spotted this with the office parser, but it should be general. The user creates a TikaInputStream, and passes that off to the parser framework. The Parser that is called may wish to spot that the input is a File backed TikaInputStream, and take a shortcut to use the file instead of the InputStream.
> However, what the parser gets is a TaggedInputStream wrapping a CountingInputStream wrapping the original TikaInputStream. As such, it can't get at the file.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira