You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by "Tim Allison (JIRA)" <ji...@apache.org> on 2018/07/31 11:17:00 UTC

[jira] [Comment Edited] (TIKA-2693) Tika 1.17 uses the wrong classloader for reflection

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

Tim Allison edited comment on TIKA-2693 at 7/31/18 11:16 AM:
-------------------------------------------------------------

I think we’re planning on releasing 1.19 in a few weeks[1], but I look forward to upgrading POI to 4.0.0 as soon as it’s available...might make it into 1.19? If not, we can roll 1.20 in early/mid Sept.?

We may have a collision w Jackcess... will need to check.

[1] All time units and estimates are in “open source time” and may have little connection to an actual calendar.


was (Author: tallison@mitre.org):
I think we’re planning on releasing 1.19 in a few weeks[1], but I look forward to upgrading POI to 4.0.0 as soon as it’s available...might make it into 1.19? If not, we can roll 1.20 in early/mid Sept.?

[1] All time units and estimates are in “open source time” and may have little connection to an actual calendar.

> Tika 1.17 uses the wrong classloader for reflection
> ---------------------------------------------------
>
>                 Key: TIKA-2693
>                 URL: https://issues.apache.org/jira/browse/TIKA-2693
>             Project: Tika
>          Issue Type: Bug
>          Components: general
>    Affects Versions: 1.17
>            Reporter: Karl Wright
>            Priority: Major
>
> I don't know whether this was addressed in 1.18, but Tika seemingly uses the wrong classloader when loading some classes by reflection.
> In ManifoldCF, there's a two-tiered classloader hierarchy.  Tika runs in the higher class level.  Its expectation is that classes that are loaded via reflection use the classloader associated with the class that is resolving the reflection, NOT the thread classloader.  That's standard Java practice.
> But apparently there's a place where Tika doesn't do it that way:
> {code}
> Error tossed: org/apache/poi/POIXMLTextExtractor
> java.lang.NoClassDefFoundError: org/apache/poi/POIXMLTextExtractor
>         at org.apache.tika.parser.microsoft.ooxml.OOXMLParser.parse(OOXMLParser.java:106) ~[?:?]
>         at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) ~[?:?]
>         at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) ~[?:?]
>         at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) ~[?:?]
>         at org.apache.manifoldcf.agents.transformation.tika.TikaParser.parse(TikaParser.java:74) ~[?:?]
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)