Uwe Ryssel created ODFTOOLKIT-396:
-------------------------------------
Summary: SpreadsheetDocument.appendSheet fails because of buggy
alien element cloning
Key: ODFTOOLKIT-396
URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-396
Project: ODF Toolkit
Issue Type: Bug
Components: odfdom
Affects Versions: 0.6.1-incubating
Environment: Windows
Reporter: Uwe Ryssel
We use the method SpreadsheetDocument.appendSheet(Table refTable, String name)
to copy/clone sheets of existing ODF files. For a specific file, we get a
NullPointer exception during this call. One of my students has posted this
issue in the incubator-odf-users mailing list yet (see topic "Working with
spreadsheet templates in odftoolkit 0.6.1" in November 2014).
I have investigated this issue a bit further and found following issue:
When using appendSheet with a given Table object, the containing
TableTableElement is cloned. But if this element contains an OdfAlienElement,
this cloning will fail.
When an OdfElement is cloned, the method OdfFileDom.newOdfElement() is called
with the corresponding class object (OdfAlienElement.class in this case).
OdfFileDom.newOdfElement() gets the value of the field ELEMENT_NAME by calling
clazz.getField("ELEMENT_NAME").get(null), which is only valid for static
fields. But OdfAlienElement's ELEMENT_NAME is not static (in opposite to the
other OdfElements), which creates the mentioned NullPointer exception. I
understand that ELEMENT_NAME cannot be static, because there is no common name
for all OdfAlienElements.
To fix the bug, I think, the OdfElement.cloneNode() have to be overwritten for
OdfAlienElement to prevent the calling of OdfFileDom.newOdfElement().
In the example file the OdfAlienElement contains the XML element
<table:table-protection
table:select-unprotected-cells="true"></table:table-protection>. The ODF file
is created originally from an Excel file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
