[ 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