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.
We use the DataEditorSupport that extends org.openide.text.CloneableEditorSupport. After writing changes to FileObject text is not modified in editor although the file is changed. We use the following procedure : - lock FileObject - gain FO output stream - write to output stream - close output stream - release lock 2-3 weeks ago there were no problems
The best text case is the issue 56586. - text in TLD editor is not refreshed after tag handler name is changed. This change triggers then change in TLD file.
Text refresh works perfectly for me. Issue 56586 talks about reload dialog, which is shown only when the document is modified in the editor, when the "external" change comes, which is correct behaviour. You need to figure out why is the editor in the modified state.
I've verified that the reload does NOT work for Web/refactoring. After renaming the tag handler, the definition library xml file is not refreshed in the editor. I've traced the problem down the whole stack and found that the refresh correctly occurs, the document is reloaded, the final document contains correct bits yet the editor still paint the old bits. I thus believe that the problem is inside editor.
That could possibly be some sort of undo that could restore the content. I'll add some debugging support to be able to discover this. BTW Milane, could you please check the dev build prior March 16 (when issue 51872 was integrated) and after that date? Thanks.
It works fine prior to March 16. I've tested that. Milan
Created attachment 21253 [details] dead-lock
Created attachment 21254 [details] dead-lock1
Created attachment 21255 [details] dead-lock2
I see no deadlock in your logs, maybe an infinite loop?
Yes, maybe. Nevertheless, the IDE freeses up. As currently many issues depend on this and it causes big regressions in J2EE area I am increasing the priority to P1.
There is a UNIT test in xml/multiview/test that can be used as a test case. See specifically XmlMultiviewEditorTest:testExternalChange() method.
I should have at least a partial fix so that the infinite loop is avoided. I'm running the test now I'll integrate within an hour.
Partially fixed in main trunk (the infinite loop should now be avoided): Checking in src/org/openide/text/CloneableEditorSupport.java; /cvs/openide/src/org/openide/text/CloneableEditorSupport.java,v <-- CloneableEditorSupport.java new revision: 1.149; previous revision: 1.148 I continue to search for a complete fix.
Yes, I cannot reproduce the infinite loop. It seems that document is refreshed sometimes, sometimes (very often) not.
The problem is following: Here is part of our code: FileLock lock = fo.lock(); try { OutputStream os = fo.getOutputStream(lock); try { writing = true; write(os); } finally { os.close(); } } finally { lock.releaseLock(); } Statement os.close() fires event that invokes reloadDocument() in CloneableEditorSupport. It reloads data from file and then it calls something in AWT thread, that calls notifyModify() in CloneableEditorSupport. It tries to get lock of the file object. If processing of events fired by os.close() is not finished yet, takeLock() fails and reloading is undone. From my point of view it is incorrect that reloadDocument() causes notifyModify() even though it is followed by notifyUnmodify().
*** Issue 57254 has been marked as a duplicate of this issue. ***
*** Issue 57275 has been marked as a duplicate of this issue. ***
The notifyModified() is called at the end of the atomic section in response to remove() and insertString() done in the document during reload. The difference after fix of issue 51872 is that the notifyModified() is no longer connected directly with the DocumentListener firing but has a special treatment and the notifyModified() is now (in the final version of the fix) called AFTER the atomic section is finished in case there were any edits done. We had tried to call it before as well and call notifyUnmodified() at the end if there were no modifications but there were too many calls to those as there is relatively many empty atomic sections calls (e.g. they are wrapping undo checking to prevent deadlock of undo manager against document) so it was changed to the current behavior. I compare the reload behavior before and after 51872 fix and I try to mask out the notifyModify() during reload whether that helps.
I prohibit the notifyModified() / notifyUndmoified() during reload. That should help to not attempt to take the file lock by CES during notifyModified() which should resolve the problem. The question still is why we did not see this in the past already - if I'm not mistaken the notifyModified() was called in the past as well and even sooner than now. The present fix uses 'revertingUndoOrReloading' flag which is set either during reverting of undo for readonly file to prevent notifyModified() call or in case of reloading of the document after external change. Everything is described in detail in the source and can be found by searching for "#57104". The present tests for notifymodified() (both the ones in openide and the inherited ones in the editor) still pass after this fix. Fixed in main trunk: Checking in src/org/openide/text/CloneableEditorSupport.java; /cvs/openide/src/org/openide/text/CloneableEditorSupport.java,v <-- CloneableEditorSupport.java new revision: 1.150; previous revision: 1.149 I mark this issue as fixed but still Yarda should review it and possibly change it if necessary. I'll write an email to him.
*** Issue 57341 has been marked as a duplicate of this issue. ***
cvs ci -m "#57104: Adding tons of logging to find out that undoredo listener is attached at non-deterministic place during document reload. Moving the registration after the last invokeLater during reload. All related tests now pass" Checking in openide/src/org/openide/text/CloneableEditorSupport.java; /cvs/openide/src/org/openide/text/CloneableEditorSupport.java,v <-- CloneableEditorSupport.java new revision: 1.152; previous revision: 1.151 done Checking in openide/test/unit/src/org/openide/text/NotifyModifiedTest.java; /cvs/openide/test/unit/src/org/openide/text/NotifyModifiedTest.java,v <-- NotifyModifiedTest.java new revision: 1.8; previous revision: 1.7 done Checking in editor/libsrc/org/netbeans/editor/BaseDocument.java; /cvs/editor/libsrc/org/netbeans/editor/BaseDocument.java,v <-- BaseDocument.java new revision: 1.122; previous revision: 1.121
I've tested several scenarios of external modification, both manual and CVS. I've tried undo to see if the file gets the modified mark properly (related recent issue). Everything works fine on build 200504062223.
"#57104,#56963: Backport of undo/redo/save fixes in editor" Checking in openide/src/org/openide/text/CloneableEditorSupport.java; /cvs/openide/src/org/openide/text/CloneableEditorSupport.java,v <-- CloneableEditorSupport.java new revision: 1.150.2.1; previous revision: 1.150 done Checking in openide/test/unit/src/org/openide/text/NbLikeEditorKit.java; /cvs/openide/test/unit/src/org/openide/text/NbLikeEditorKit.java,v <-- NbLikeEditorKit.java new revision: 1.4.4.1; previous revision: 1.4 done Checking in openide/test/unit/src/org/openide/text/NotifyModifiedTest.java; /cvs/openide/test/unit/src/org/openide/text/NotifyModifiedTest.java,v <-- NotifyModifiedTest.java new revision: 1.6.4.1; previous revision: 1.6 done Checking in editor/libsrc/org/netbeans/editor/BaseDocument.java; /cvs/editor/libsrc/org/netbeans/editor/BaseDocument.java,v <-- BaseDocument.java new revision: 1.119.2.1; previous revision: 1.119 done Checking in editor/libsrc/org/netbeans/editor/BaseDocumentEvent.java; /cvs/editor/libsrc/org/netbeans/editor/BaseDocumentEvent.java,v <-- BaseDocumentEvent.java new revision: 1.21.2.1; previous revision: 1.21
Verified in 200507131800.