[ https://issues.apache.org/jira/browse/TIKA-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16558986#comment-16558986 ]
Andreas Beeker commented on TIKA-2693: -------------------------------------- The NoClassDefFoundError happens, because I suggested to use POI 4.0.0, but 4.0.0 has API-breaks caused by [#62355|https://bz.apache.org/bugzilla/show_bug.cgi?id=62355] - and a moved POIXMLTextExtractor is one of them. So this has to be tested after Tika is adapted to POI 4.0.0. > 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)