|Summary:||Excel Messages on xl/tables XMLs|
|Product:||POI||Reporter:||Stefan Esch <stefan.esch>|
|Component:||XSSF||Assignee:||POI Developers List <dev>|
|Attachments:||Sample program to reproduce behavior|
Description Stefan Esch 2015-02-20 09:47:08 UTC
Hello, after upgrading from POI 3.8 to POI 3.10.1 my application is generating XLSX files, which are not accepted completely by Excel 2010 or later. Excel is reporting inconsistencies in the file and offering, to repair those. Reparing creates messages like "Repaired Records: Table from /xl/tables/table1.xml part (Table)". Functionally the XLSX seems to be fine after repair and my application can still consume it with POI library. Anyway, I am concerned about my users complaining about my application creating inconsistent XLSX file so that I would like to have you providing me guidance on how to get that fixed (either by a patch for POI 3.10.1 or instructions on how to adjust my Java Coding). Kindly note, that POI 3.11 or later is no viable option, because my application has to be build with Java 1.5. Please find attached a sample program to reproduce the behavior without all my additional application logic. POI_Sample simply reads by raw XLSX template file into a POI Workbook and writes that Workbook back to a ByteArray and a File. I would expect the XLSX not being changed at all in course of that. Instead POI_Sample aborts with following stacktrace when writing the Workbook to the file: org.apache.xmlbeans.impl.values.XmlValueDisconnectedException at org.apache.xmlbeans.impl.values.XmlObjectBase.check_orphaned(XmlObjectBase.java:1258) at org.apache.xmlbeans.impl.values.XmlObjectBase.newCursor(XmlObjectBase.java:286) at org.apache.xmlbeans.impl.values.XmlComplexContentImpl.arraySetterHelper(XmlComplexContentImpl.java:1124) at org.openxmlformats.schemas.spreadsheetml.x2006.main.impl.CTDefinedNamesImpl.setDefinedNameArray(Unknown Source) at org.apache.poi.xssf.usermodel.XSSFWorkbook.saveNamedRanges(XSSFWorkbook.java:1288) at org.apache.poi.xssf.usermodel.XSSFWorkbook.commit(XSSFWorkbook.java:1309) at org.apache.poi.POIXMLDocumentPart.onSave(POIXMLDocumentPart.java:322) at org.apache.poi.POIXMLDocument.write(POIXMLDocument.java:179) at POI_Sample.main(POI_Sample.java:43) Any help is highly appreciated. Thank You, Stefan
Comment 1 Stefan Esch 2015-02-20 10:03:55 UTC
Created attachment 32501 [details] Sample program to reproduce behavior Executable JAR created with Eclipse 3.3.x, POI library files excluded from JAR to meet upload requirements. Please use poi-bin-3.10.1-20140818.zip to execute class POI_Sample.
Comment 2 Nick Burch 2015-02-21 12:46:52 UTC
Any chance you could try with a recent POI nightly build (on a newer JVM just for testing), and see if the problem remains? That'll let you work out if you need to backport an existing fix, or if the problem remains to be solved acorss all versions?
Comment 3 Stefan Esch 2015-02-23 07:45:12 UTC
(In reply to Nick Burch from comment #2) Hi Nick, all I can try is changing the POI version for my sample program. I will give that a try and share results. Finally I still would need a solution working with POI 3.10.1 (or at least same JVM) because there is no chance to increase the JVM version for the entire application. I will share test results, soon. Thank You, Stefan
Comment 4 Stefan Esch 2015-02-23 13:24:23 UTC
Hi Nick, I did try my sample program on JRE 1.6 with POI library 3.11 binary of December, 2014. It completes successfully and writes a XLSX to the file system accepted by MS Excel. So far so good. It seems POI release 3.11 having solved the issue delivered with release 3.10.1. For your reference, I did update from release 3.8 to 3.10.1 in order to run into the issue. The XSLX file created with release 3.8 had been fine. Does hat give you a clue where to look at in release 3.10.1? Thank You, Stefan
Comment 5 Stefan Esch 2015-04-14 15:03:56 UTC
Hello, can anyone please support on how to get the solution downported from 3.11 to 3.10.1 because a secure libary running on Java EE 5 is required ? I already tried to build 3.10.1 locally from the sources provided but I am constantly failing, because some OOXML basic types are missing. I tried to work around that known issue by using OOXL libraries shipped with releases 3.8 and 3.9, but they are not compatible with 3.10.1 either. I am now at trying to recompile releases 3.11 with Java EE 5. As you might see, I am really lost. Any help would be highly appreciated. Thank You, Stefan
Comment 6 Dominik Stadler 2015-04-15 20:12:20 UTC
If you really need to backport this I would try to check out the source of 3.10.1 from https://svn.apache.org/repos/asf/poi/branches/REL_3_10_BRANCH/ and build from there as the official release was also built from that. However we are currently not planning to officially down-port features/fixes to previous versions as our available development resources are scarce and this would take away even more of the time people can spend on new bugfixes and features. BTW, Java 5 is deprecated and unsupported for a long time now. Even Java 6 is already unsupported and deprecated for some time and Java 7 is currently entering desupport mode.
Comment 7 Stefan Esch 2015-04-16 07:14:11 UTC
Hello Dominik, I will create the downport from the sources specified and deliver a version 3.11.downported with my application. Please let me know if you want to have a copy of the downported version for your archives. Thank you for the clarification on the support strategy for the library. I completely agree with that especially in respect to the deprecated Java Releases. Unfortunately that conflicts with the company me being with is provided support for the application build on top of the POI library until year 2020 simply ignoring deprecation of used technologies. Thank You, Stefan
Comment 8 Dominik Stadler 2015-04-16 10:07:16 UTC
Hi, the binaries of the downport are likely not useful as we would not be able to use them due to security and licensing concerns anyway, but if you want to contribute the work you can paste a patch of the resulting changes here on this bug entry so we have it available if someone else needs it.