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

Ken Krugler commented on TIKA-514:
----------------------------------

Another suggestion was to catch exceptions thrown in the TikaConfig 
constructor, while instantiating parsers.

But in the past this hadn't generated much excitement from people developing 
custom parsers, as it would mask errors until later.

Nick suggested an alternative:

{quote}
My thinking on exceptions during creating the parser are:
* ClassNotFound for parser class - throw the exception, as the user has
 specified a parser that isn't there
* Any other ClassNotFound - warning, as this means that a dependency is
 missing, but that may be what the user wanted
* Any other problem - throw the exception, as there is a fault with the
 parser, and there's a fair chance that this is a customer parser
 that has broken. (The standard tika parsers shouldn't do this!)
{quote}

I'd added one comment:

{quote}
If you use this approach, then you'd also want to do this special handling for 
the NoSuchMethodError, as that was getting thrown by Tika 0.7-SNAPSHOT when POI 
support was excluded.
{quote}


> Provide constructor for AutoDetectParser that has explicit list of supported 
> parsers
> ------------------------------------------------------------------------------------
>
>                 Key: TIKA-514
>                 URL: https://issues.apache.org/jira/browse/TIKA-514
>             Project: Tika
>          Issue Type: Improvement
>    Affects Versions: 0.7
>            Reporter: Ken Krugler
>            Assignee: Ken Krugler
>             Fix For: 0.8
>
>
> To reduce the size of the Tika dependency chain, it's useful to exclude the 
> supporting jars for types that don't need to process (e.g. Microsoft docs, 
> PDFs, etc). This can easily remove 20MB of 3rd party jars.
> With 0.8-SNAPSHOT, the TikaConfig(Classpath) constructor now finds and 
> instantiates all Parser-based classes found on the classpath. Which can 
> trigger errors when 3rd party jars are missing.
> One solution, as proposed by Jukka, is to provide an alternative constructor 
> for AutoDetectParser which includes the list of supported parsers, and avoids 
> creating the default TikaConfig.

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

Reply via email to