[
https://issues.apache.org/jira/browse/TIKA-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16563464#comment-16563464
]
Tim Allison commented on TIKA-2693:
-----------------------------------
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)
