Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <19814674.260681290522733906.JavaMail.jira@thor>
Date: Tue, 23 Nov 2010 09:32:13 -0500 (EST)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Resolved: (JCR-2642) JackrabbitParser and tika 0.7 parser
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/JCR-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting resolved JCR-2642.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 2.2.0
         Assignee: Jukka Zitting

We need the custom tika-config.xml file since we want to by default disable text extraction of package and image file formats to avoid excess resources being spent.

However, in revision 1038125 I modified our custom tika-config.xml file to use the new DefaultParser class in Tika 0.8 to automatically pick up all available parser classes through the service provider mechanism used by Tika. The selected package and image formats are still disabled by explicitly mapping them to the dummy EmptyParser class.

> JackrabbitParser and tika 0.7 parser
> ------------------------------------
>
>                 Key: JCR-2642
>                 URL: https://issues.apache.org/jira/browse/JCR-2642
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>    Affects Versions: 2.1.0
>            Reporter: Dan Ducar
>            Assignee: Jukka Zitting
>             Fix For: 2.2.0
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Hi,
> I was trying to implement a custom parser and found the following problem.
> Since tika 0.7 it is possible to implement your custom parser and specify it into a service provider configuration file (META-INF/services/org.apache.tika.parser.Parser). In this way there would be no need to maintain a custom tika-config.xml file if you'd like to implement a custom parser.
> The problem that I had was in the JackrabbitParser because I wasn't able to instantiate the AutoDetectParser with the default constructor is will be instantiated using the default TikaConfig constructor.
> Basically from tika 0.7, the TikaConfig.getTikaConfig() is instantiating the TikaConfig using the default constructor instead of accessing the tika-config.xml file from withing the package, and reads the service provider configuration files and populate the parsers map.
> What I'm proposing is to change the JackrabbitParser to instantiate the AutoDetectParser using the default constructor, in this way the using tika version >= 0.7 we could easily implement our own parsers and there won't be a reason to maintain the tika-config.xml, also a sort of "backward" compatibility would be maintained because using the AutoDetectParser default constructor the TikaConfig is instantiated using TikaConfig.getTikaConfig() wich for tika versions < 0.7 calls the TikaConfig(InputStream) constructor whcih reads the configuration directly from the package.
> Basically the JackrabbitParser should look like this:
>     public JackrabbitParser() {
>             	parser = new AutoDetectParser();
>     }
>  
> Thanks,
> Dan

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.