Bug 59128 - ooxml-schemas 1.3 and ooxml-security 1.1 have outdated xmlbeans dependency
Summary: ooxml-schemas 1.3 and ooxml-security 1.1 have outdated xmlbeans dependency
Status: RESOLVED WONTFIX
Alias: None
Product: POI
Classification: Unclassified
Component: XSSF (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-05 20:41 UTC by David North
Modified: 2016-03-07 08:32 UTC (History)
0 users


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David North 2016-03-05 20:41:18 UTC 
The full-scope schema JARs, ooxml-schemas 1.3 and ooxml-security 1.1 depend on xmlbeans 2.3. It should be 2.6 to match the dependency in the rest of POI.

See:

http://mvnrepository.com/artifact/org.apache.poi/ooxml-schemas/1.3
http://mvnrepository.com/artifact/org.apache.poi/ooxml-security/1.1

In practice this probably doesn't matter as users using these will also be depending on poi-ooxml, which will pull in xmlbeans 2.6.0 via transitive dependencies to poi-ooxml-schemas, and most Maven/Ivy-like tools will evict 2.3.0 in favour of 2.6.0 to resolve the clash.

We should fix this, though, presumably by issuing ooxml-schemas 1.3.1 and ooxml-security 1.1.1.
Comment 1 Nick Burch 2016-03-05 20:44:00 UTC 
This is deliberate - xmlbeans runtimes will run older-compiled schemas but not newer ones. As such, we compile against the oldest feasible version we can (2.3), but ship 2.6 as the suggested runtime. This means that most people will use 2.6, but anyone who needs to can stick with 2.3, 2.4 or 2.5 (if their framework etc ships only that)
Comment 2 Andreas Beeker 2016-03-05 20:51:39 UTC 
I wonder if it still makes sense to be downward compatible, since we've switched to Java 6 and there are probably not many good reasons to stick with xmlbeans 2.3 ...
Comment 3 David North 2016-03-05 20:55:59 UTC 
Sorry, I should have made it clear how I arrived at raising this bug.

With the following JARs on its classpath:

poi-3.14-20160307.jar
poi-ooxml-3.14-20160307.jar
poi-ooxml-schemas-3.14-20160307.jar
xmlbeans-2.3.0.jar


The following piece of code:

new XSSFWorkbook();


Fails with a stack trace:

Exception in thread "main" java.lang.NoSuchMethodError: org.apache.xmlbeans.XmlOptions.setLoadEntityBytesLimit(I)Lorg/apache/xmlbeans/XmlOptions;
	at org.apache.poi.POIXMLTypeLoader.<clinit>(POIXMLTypeLoader.java:50)
	at org.openxmlformats.schemas.spreadsheetml.x2006.main.CTWorkbook$Factory.newInstance(Unknown Source)
	at org.apache.poi.xssf.usermodel.XSSFWorkbook.onWorkbookCreate(XSSFWorkbook.java:425)

Looking at the commits on POIXMLTypeLoader suggests that the fix to 58617 means we do now require XMLBeans 2.6.0 at runtime (or at any rate, one new enough to contain setLoadEntityBytesLimit, which 2.3.0 does not).
Comment 4 Andreas Beeker 2016-03-05 21:06:03 UTC 
with my patch for ##57031 the dependency on xmloptions.setLoadEntityBytesLimit() will be obsolete, as jaxp will be used then, which already has this secure parsing feature ...
Comment 5 David North 2016-03-07 08:32:26 UTC 
OK, in that case it looks like we can take no action and leave further work on this to bug 57031. Wontfixing again.