https://bz.apache.org/bugzilla/show_bug.cgi?id=61478
--- Comment #22 from Karl Wright <[email protected]> --- If there are no invocations of Class.forName(String, boolean, ClassLoader), then there's no way the POI libraries can be a problem. But a glance at the code shows that that's not entirely true; the POIXMLTypeLoader class does the latter. It may be the case that the only reason for that code was written was to work around this problem when it was discovered by others (e.g. #60226). But, in that case, the problem might well be that some other dependency, e.g. xmlbeans, is doing the wrong thing and you guys need to request a fix from them. Here are some data points: - Running all poi jars and their dependencies at the "connectors" level with poi-3.15 *definitely* uses the wrong classloader at some point -- probably the thread classloader - The testbed I constructed and uploaded, on the other hand, *succeeds* - and that setup mimics MCF's classloader setup, but without Tika in between the MCF "connector" and the poi jars Maybe the right approach is to analyze the difference in code paths between these two ways of calling into poi and see what differences there are, if any? The stack traces are helpful here, yes, but maybe also looking at the testbed I uploaded could provide some insight into a way of getting into poi that does not seem to have the problem? The only thing I'm pretty sure of is that it probably isn't Tika that does this, because it *does* manage to find the poi classes, just not those in poi-ooxml-schemas. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
