Bug 59195 - POIXMLTypeLoader depends on XMLBeans 2.6.0
Summary: POIXMLTypeLoader depends on XMLBeans 2.6.0
Status: RESOLVED DUPLICATE of bug 59268
Alias: None
Product: POI
Classification: Unclassified
Component: XSSF (show other bugs)
Version: 3.14-FINAL
Hardware: PC Windows NT
: P2 regression (vote)
Target Milestone: ---
Assignee: POI Developers List
Depends on: 59268
  Show dependency tree
Reported: 2016-03-18 07:24 UTC by Dominik Stadler
Modified: 2016-08-13 20:45 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Dominik Stadler 2016-03-18 07:24:56 UTC
Seems we introduced a dependency on XMLBeans > 2.3.0, see the discussion at http://stackoverflow.com/questions/36063592/exception-in-thread-main-org-apache-poi-poixmlexception-exception-appearing-wh

Caused by: java.lang.NoSuchMethodError: org.apache.xmlbeans.XmlOptions.setLoadEntityBytesLimit(I)Lorg/apache/xmlbeans/XmlOptions;
    at org.apache.poi.POIXMLTypeLoader.<clinit>(POIXMLTypeLoader.java:50)
    at org.apache.poi.xssf.model.ThemesTable.<init>(ThemesTable.java:85)
    ... 10 more

Either we should update to XMLBeans 2.6.0 officially or try to work around this by catching the NoSuchMethodError at this place.

If we want to stay compatible, we also should enhance the "source build tests" in src/integrationtest/build.xml to run a full build/test with XMLBeans 2.3.0 to verify that it keeps working in the future.
Comment 1 Andreas Beeker 2016-03-18 07:34:26 UTC
I guess the call can be removed, as the xml streams are now processed via jaxp instead of the picollo parser. To make sure, that the picollo parser isn't used incidentally, how about removing its classes from the xmlbeans jars within the ant build?
Comment 2 Andreas Beeker 2016-03-18 21:40:37 UTC
I've removed the piccolo classes in the xmlbeans jars used for our build via r1735685
The failing XmlOption is now also disabled, as JAXP is used for parsing.

As we require JDK 6 as a minimum, I still don't see a reason for not upgrading to xmlbeans 2.6.0, i.e. asking our users to upgrade as we usually do for our own releases ...
Comment 3 Nick Burch 2016-03-18 21:50:39 UTC
Xmlbeans is shipped with all sorts of frameworks and runtimes and application servers, so upgrading can be hard. Also, the xmlbeans 2.6.0 jars are broken, which means some refuse to upgrade, or really struggle due to the need to repack it

Maybe we could get together with Tika and Lucene, and ask the Attic PMC to let us put together a 2.6.1 release with the packaging fix and some others, if someone fancies spending a little bit of time to lead that?

(I'd be much happier, if we do force people to upgrade, to make them upgrade to a non-broken release!)
Comment 4 Andreas Beeker 2016-03-18 21:59:10 UTC
for the sake of completeness I link the thread [1] which mention the locking problem in xmlbeans. I have already forgotten about it ... :(

[1] http://apache-poi.1045710.n5.nabble.com/Alternative-Replacement-for-xmlbeans-tt5722053.html
Comment 5 Dominik Stadler 2016-08-13 20:45:42 UTC
I think the best fix here will be to produce an updated XmlBeans which fixes the issues and allows us to depend on it alone and not 2.3.0 any more as this can cause all sorts of strange issues, thus I am closing this as duplicate of Bug 59268 for now.

*** This bug has been marked as a duplicate of bug 59268 ***