https://bz.apache.org/bugzilla/show_bug.cgi?id=62484
Bug ID: 62484 Summary: XSSFRow:OnDocumentWrite Unordered row will generate CTCells that are not referenced by _cells Treemap Product: POI Version: 3.17-FINAL Hardware: All OS: All Status: NEW Severity: blocker Priority: P2 Component: XSSF Assignee: dev@poi.apache.org Reporter: fr...@tygron.com Target Milestone: --- I have a Microsoft Excel file which has several rows that are not ordered alphabetically. Reading and writing to this Excel file will work well, until I write the XSSF-document to a file for the first time. When I continued reading from and writing to cells in this document, I noticed some cells did not update properly in the CTRows of XSSFRows. I debugged deeper and noticed that onDocumentWrite, for XSSFRows that are not ordered, new CTCells are created through a copy. I understand this code and it seemed logical. <code from XSSFRow::OnDocumentWrite> if(!isOrdered){ cArray = new CTCell[_cells.size()]; int i = 0; for (XSSFCell xssfCell : _cells.values()) { cArray[i] = (CTCell) xssfCell.getCTCell().copy(); // we have to copy and re-create the XSSFCell here because the // elements as otherwise setCArray below invalidates all the columns! // see Bug 56170, XMLBeans seems to always release previous objects // in the CArray, so we need to provide completely new ones here! // _cells.put(entry.getKey(), new XSSFCell(this, cArray[i])); // xssfCell.setCTCell(cArray[i]); i++; } _row.setCArray(cArray); } However, when this new CTCell array is set to the CTRow: _row.setCArray(cArray); code in this method can (or often will) also copy these Cell objects again for its own internal row. (The underlying classes and methods doing this are: XmlComplexContentImpl::arraySetterHelper( XmlObject[] sources, QName elemName) XmlObject::set(XmlObject src) -> if (monitor() == obj.monitor()) // both are in the same locale { if (noSyncThis) // the locale is not sync newObj = setterHelper( obj ); else // the locale is sync { synchronized (monitor()) { newObj = setterHelper( obj ); <-- new CTCell object is created } } } ) The result is that the CTRow will now reference other CTCells than the _cells TreeMap of the XSSFRow. Writing new values to these cells will only end up in the _cells TreeMap and not in the CTRow any more. Consequently, writing the document a second time after having changed cell values in these rows will write the wrong cell values. Hopefully others are also able to reproduce this issue! -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org