[
https://issues.apache.org/jira/browse/TIKA-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240469#comment-13240469
]
Nick Burch commented on TIKA-886:
---------------------------------
For cases where the OPCPackage is opened in ZipContainerDetector, then the
OPCPackage is added as the OpenContainer on the TikaInputStream and is closed
correctly when the stream is closed. For cases where OOXMLExtractorFactory does
the open, it should likewise set it as the container so it is closed. For pure
stream based creation, there is no state left to close, this only affects the
case of opening the OPCPackage from a File.
(Having OOXMLExtractorFactory do the close itself feels wrong, as it might end
up closing something that someone else opened, and having it track who opened
it with different code paths doesn't feel right. Making the two cases behave
the same feels simplest)
> OOXMLExtractorFactory can leave files open
> ------------------------------------------
>
> Key: TIKA-886
> URL: https://issues.apache.org/jira/browse/TIKA-886
> Project: Tika
> Issue Type: Bug
> Components: parser
> Affects Versions: 1.1
> Reporter: Nick Burch
> Assignee: Nick Burch
> Fix For: 1.2
>
>
> As identified in an Alfresco bug (ALF-13106), OOXMLExtractorFactory doesn't
> currently allow the closing of OPCPackage instances created from Files. This
> is because the OPCPackage isn't associated with the TikaInputStream, so the
> close doesn't propogate
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
