poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 61478] POI OOXML-Schema lookup uses wrong classloader
Date Sun, 03 Sep 2017 08:56:54 GMT

--- Comment #22 from Karl Wright <kwright@apache.org> ---
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

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

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

View raw message