Problem can be reproduced by following these steps. 1] Shift Row2 to Row0 2] Now try shifting Row3 to Row0 you get org.apache.xmlbeans.impl.values.XmlValueDisconnectedException Here is piece of code to reproduce issue. This issue happens with 3.15-beta as well. Workbook workbook = new XSSFWorkbook(); Sheet sheet = workbook.createSheet("mySheet"); Row row = workbook.getSheet("mySheet").createRow(0); row.createCell(0).setCellValue(1.0); row.createCell(1).setCellValue(2.0); // row = workbook.getSheet("mySheet").createRow(1); row.createCell(0).setCellValue(3.0); row.createCell(1).setCellValue(4.0); row = workbook.getSheet("mySheet").createRow(2); row.createCell(0).setCellValue(5.0); row.createCell(1).setCellValue(6.0); row = workbook.getSheet("mySheet").createRow(3); row.createCell(0).setCellValue(7.0); row.createCell(1).setCellValue(8.0); row = workbook.getSheet("mySheet").createRow(4); row.createCell(0).setCellValue(9.0); row.createCell(1).setCellValue(10.0); sheet.shiftRows(2, 2, -2); sheet.shiftRows(3, 3, -3);
Verified this affects the current trunk (pre-3.15-beta2). Added a disabled unit test in r1749295. XmlValueDisconnectedExceptions occur because the links between nodes in the DOM (XML tree) are broken. This can happen when a node is freed by one node but still weakly linked to by another node. This only causes problems when the second node tries to traverse the broken link.
Probably a duplicate of bug 58221
I simplified this to creating empty rows, and the exception was still thrown by the second shiftRows call. r1749300. This isolates the problem to the CTRows causing the disconnected XML value. Workbook workbook = new XSSFWorkbook(); Sheet sheet = workbook.createSheet(); for (int r=0; r<=4; r++) { sheet.createRow(r); } // Shift the 2nd row on top of the 0th row sheet.shiftRows(2, 2, -2); sheet.shiftRows(3, 3, -3);
Will it be fixed in 3.15?
(In reply to Dattathreya from comment #4) > Will it be fixed in 3.15? It depends on if someone contributes a patch that fixes the bug. Those who are not affected by the bug are less likely to spend time fixing the bug.
Is there any temporary workarounds available for this problem?
In r1752996 I have narrowed down the testcase slightly, after the first shifting, only removing row 0 and then trying to access row 1 causes the exception.
By experiment I uncommented removeRow on the sheetData in XSSFSheets.shiftRows function. Because this decouples the original row from the xml. I now try and remove all cells instead when code decides to remove the row(s) to shift to. //worksheet.getSheetData().removeRow(idx); for(Iterator<Cell> cit = row.cellIterator(); cit.hasNext();) { row.removeCell(cit.next()); }
The related test-case was fixed as part of bug #64516, so hopefully this problem is now resolved in nightly builds, although there remain some more issues with shifting/cloning... *** This bug has been marked as a duplicate of bug 64516 ***
The related test-case was fixed as part of bug #64516, so hopefully this problem is now resolved in nightly builds, although there remain some more issues with shifting/cloning...