[
https://issues.apache.org/jira/browse/TIKA-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875756#action_12875756
]
Brad Greenlee commented on TIKA-419:
------------------------------------
Cross-posting my comment on SOLR-1902
(https://issues.apache.org/jira/browse/SOLR-1902?focusedCommentId=12875725&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12875725)
that the issue still seems to exist:
I am still seeing this issue. It works if I downgrade Tika to 0.6, but neither
the 0.8-SNAPSHOT included in the current Solr trunk nor a snapshot from the
Tika trunk work for me. I'm running Java 1.6.0_20 on OS X 10.6.3. I posted
about the issue to the solr-user mailing list:
http://lucene.472066.n3.nabble.com/TikaEntityProcessor-not-working-td856965.html
> Allow parser lookup from a custom class loader
> ----------------------------------------------
>
> Key: TIKA-419
> URL: https://issues.apache.org/jira/browse/TIKA-419
> Project: Tika
> Issue Type: Improvement
> Components: config
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Fix For: 0.8
>
>
> Since TIKA-317 we've used the
> javax.imageio.spi.ServiceRegistry.lookupProviders(Class<?>) method to look up
> all the currently available Parser implementations. This method uses the
> context class loader of the current thread for looking up Parser classes.
> As seen in NUTCH-810 and discussed on tika-users@, this is troublesome for
> applications with more complex class loading mechanisms. To solve the issue,
> it would be good to allow the client to optionally specify an explicit class
> loader instance from which parsers are to be looked up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
