[
https://issues.apache.org/jira/browse/TIKA-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Allison updated TIKA-1611:
--
Description:
While parsing embedded documents, currently, if a parser hits an
EncryptedDocumentException or anything wrapped in a TikaException, the
Exception is swallowed by {{ParsingEmbeddedDocumentExtractor}}:
{noformat}
DELEGATING_PARSER.parse(
newStream,
new EmbeddedContentHandler(new
BodyContentHandler(handler)),
metadata, context);
} catch (EncryptedDocumentException ede) {
// TODO: can we log a warning that we lack the password?
// For now, just skip the content
} catch (TikaException e) {
// TODO: can we log a warning somehow?
// Could not parse the entry, just skip the content
} finally {
tmp.close();
}
{noformat}
For some applications, it might be better to store the stack trace of the
attachment that caused an exception.
The proposal would be to include the stack trace in the metadata object for
that particular attachment.
The user will be able to specify whether or not to store stack traces, and the
default will be to store stack traces. This will be a small change to the
legacy behavior.
was:
While parsing embedded documents, currently, if a parser hits an Exception, the
Exception is swallowed by {{ParsingEmbeddedDocumentExtractor}}:
{noformat}
DELEGATING_PARSER.parse(
newStream,
new EmbeddedContentHandler(new
BodyContentHandler(handler)),
metadata, context);
} catch (EncryptedDocumentException ede) {
// TODO: can we log a warning that we lack the password?
// For now, just skip the content
} catch (TikaException e) {
// TODO: can we log a warning somehow?
// Could not parse the entry, just skip the content
} finally {
tmp.close();
}
{noformat}
For some applications, it might be better to store the stack trace of the
attachment that caused an exception.
The proposal would be to include the stack trace in the metadata object for
that particular attachment.
The user will be able to specify whether or not to store stack traces, and the
default will be to store stack traces. This will be a small change to the
legacy behavior.
Allow RecursiveParserWrapper to catch exceptions from embedded documents
Key: TIKA-1611
URL: https://issues.apache.org/jira/browse/TIKA-1611
Project: Tika
Issue Type: Improvement
Components: core
Reporter: Tim Allison
Assignee: Tim Allison
Priority: Minor
Fix For: 1.9
While parsing embedded documents, currently, if a parser hits an
EncryptedDocumentException or anything wrapped in a TikaException, the
Exception is swallowed by {{ParsingEmbeddedDocumentExtractor}}:
{noformat}
DELEGATING_PARSER.parse(
newStream,
new EmbeddedContentHandler(new
BodyContentHandler(handler)),
metadata, context);
} catch (EncryptedDocumentException ede) {
// TODO: can we log a warning that we lack the password?
// For now, just skip the content
} catch (TikaException e) {
// TODO: can we log a warning somehow?
// Could not parse the entry, just skip the content
} finally {
tmp.close();
}
{noformat}
For some applications, it might be better to store the stack trace of the
attachment that caused an exception.
The proposal would be to include the stack trace in the metadata object for
that particular attachment.
The user will be able to specify whether or not to store stack traces, and
the default will be to store stack traces. This will be a small change to
the legacy behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
