This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
See URL: java.util.NoSuchElementException at java.util.LinkedList.getFirst(LinkedList.java:109) at org.netbeans.modules.refactoring.spi.impl.UndoManager.addItem(UndoManager.java:252) at org.netbeans.modules.refactoring.spi.impl.UndoManager.addItem(UndoManager.java:238) at org.netbeans.modules.refactoring.api.RefactoringSession.doRefactoring(RefactoringSession.java:100) at org.netbeans.modules.refactoring.spi.impl.ParametersPanel$8.run(ParametersPanel.java:328) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:541) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:963)
The test does this: - call cut action on java node - call paste action on package node - confirm Move Class dialog but at this point it failed and class was not moved
*** Issue 93340 has been marked as a duplicate of this issue. ***
Another failure: http://deadlock.nbextras.org/hudson/job/trunk-nightly/63/artifact/xtest/instance/results/testrun_070208-084752/testbag_4/htmlresults/suites/TEST-validation.IDECommitValidation.html#validation.IDEValidation.testProjectsView Raising priority due to frequency.
This is just consequence of the Exception before: org.openide.filesystems.FileAlreadyLockedException: hudson/workdir/jobs/trunk-nightly/workspace/xtest/instance/work/sys/ide/SampleProject/src/sample1/SampleClass11.java [ideTestRunner] at org.netbeans.modules.masterfs.Delegate.lock(Delegate.java:175) [ideTestRunner] at org.netbeans.modules.masterfs.MasterFileObject.lock(MasterFileObject.java:165) [ideTestRunner] at org.openide.loaders.MultiDataObject$Entry.takeLock(MultiDataObject.java:1096) [ideTestRunner] at org.openide.loaders.FileEntry.move(FileEntry.java:82) [ideTestRunner] at org.openide.loaders.MultiDataObject.handleMove(MultiDataObject.java:587) [ideTestRunner] at org.openide.loaders.DataObject$2Op.run(DataObject.java:630) [ideTestRunner] at org.openide.loaders.DataObject$1WrapRun.run(DataObject.java:776) [ideTestRunner] at org.openide.loaders.DataObjectPool$1WrapAtomicAction.run(DataObjectPool.java:202) [ideTestRunner] at org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:98) [ideTestRunner] at org.openide.filesystems.FileSystem.runAtomicAction(FileSystem.java:471) [ideTestRunner] at org.openide.loaders.DataObjectPool.runAtomicAction(DataObjectPool.java:214) [ideTestRunner] at org.openide.loaders.DataObject.invokeAtomicAction(DataObject.java:796) [ideTestRunner] at org.openide.loaders.DataObject.move(DataObject.java:636) [ideTestRunner] at org.netbeans.modules.refactoring.plugins.FileMovePlugin$MoveFile$1.commit(FileMovePlugin.java:97) [ideTestRunner] at org.netbeans.modules.refactoring.api.RefactoringSession.doRefactoring(RefactoringSession.java:94) [ideTestRunner] at org.netbeans.modules.refactoring.spi.impl.ParametersPanel$8.run(ParametersPanel.java:328) [ideTestRunner] at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:541) [ideTestRunner] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:963) Have no idea how to reproduce.
Failed again in #2216.
Failed again in #2281. Whether or not you can reproduce this, can you at least make it stop breaking commit validation?
The root of the problem seems to be in FileAlreadyLockedException. Refactoring module does not explicitly lock files. It uses java/source module for file content manipulation and DataObject.rename()/move for metadata manipulation. I do not blame anyone. I'm just asking you guys to evaluate this issue. I'm OOO next week. Similar FileAlreadyLockedException is thrown during refactoring tests. Ask Jirka Prox.
> Similar FileAlreadyLockedException is thrown during refactoring tests. Ask Jirka Prox. Exception in tests fixed. Problem was, that Trivial impl. of LifecycleManager did not save modified objects.
Did you see this issue recently?
Yes, I already read this. But I don't have more ideas. Probably turn on the logging of FileObject.lock() FileLock.unlock() and try to reproduce it to see who holds the lock.
I meant "did anyone see this failure recently? Is this issue still valid?" :)
The problems with tests are solved as was mentioned earlier
I don't think I have seen it recently.
Let's mark this issue as fixed. Please reopen if it appears again.