tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrea (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TIKA-1740) RecursiveParserWrapper returning ContentHandler-s
Date Tue, 22 Sep 2015 14:12:04 GMT

    [ https://issues.apache.org/jira/browse/TIKA-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902694#comment-14902694

Andrea commented on TIKA-1740:

Thanks for your reply. Of course I can create my own Recursive parser, but it would be almost
identical to the RecursiveParserWrapper, just storing the ContentHandler instances too. 

> RecursiveParserWrapper returning ContentHandler-s
> -------------------------------------------------
>                 Key: TIKA-1740
>                 URL: https://issues.apache.org/jira/browse/TIKA-1740
>             Project: Tika
>          Issue Type: Wish
>          Components: core, parser
>            Reporter: Andrea
> I would like to build a mechanism to allow a custom object being built starting from
a parsing result. This can be done easily by working with a custom ContentHandler "transformer",
but how can I achieve this result using a RecursiveParserWrapper? In this case I can only
set a ContentHandlerFactory and the parser will just call the toString method and set it as
a metadata. Can you imagine something to get the entire ContentHandler object for each subfile
instead of the result of the toString method? Of course, it would also be needed to have a
flag to disable the TIKA_CONTENT metadata production.

This message was sent by Atlassian JIRA

View raw message