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.

Bug 86838 - FileRename refactoring can not be undo
Summary: FileRename refactoring can not be undo
Status: VERIFIED FIXED
Alias: None
Product: xml
Classification: Unclassified
Component: Schema Tools (show other bugs)
Version: 5.x
Hardware: All Windows XP
: P1 blocker (vote)
Assignee: Nam Nguyen
URL:
Keywords:
: 86899 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-10-10 08:44 UTC by Nam Nguyen
Modified: 2006-10-12 10:15 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
fix (11.40 KB, application/octet-stream)
2006-10-10 16:03 UTC, Nam Nguyen 		Details
A simpler and more effective fix. (5.94 KB, patch)
2006-10-10 22:55 UTC, Nam Nguyen 		Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Nam Nguyen 2006-10-10 08:44:12 UTC 
- Create async SOA sample project.
- In the project explorer, do Refactor>File Rename to rename AsyncSample.xsd to
s/t else
- Right click on the renamed file to see that Refactor > Undo|Redo command are
disabled.
Comment 1 Nam Nguyen 2006-10-10 09:18:05 UTC 
This happen on the second refactorings since the start of the IDE.  The main
cause of this "regression" is from the use of
RefactoringManager.isRunning(UsageSet) to filter out noise events.  Since this
filtering is less restrictive, the noise events from previous UsageSet listner
could reach RefactoringManager causing reset of undo managers.

The fix is to turn off listening on previous refactored models at the start of
processing the next refactoring.

Also, fix in this change is typo causing memory leaks on listeners attached to
GeneralChangeExecutor.

Fix checked into release55_dev:

/cvs/xml/refactoring/src/org/netbeans/modules/xml/refactoring/Attic/RefactoringManager.java,v
 <--  RefactoringManager.java
new revision: 1.1.2.10.2.5; previous revision: 1.1.2.10.2.4
/cvs/xml/refactoring/src/org/netbeans/modules/xml/refactoring/Attic/UsageSet.java,v
 <--  UsageSet.java
new revision: 1.1.2.7.2.4; previous revision: 1.1.2.7.2.3
/cvs/xml/refactoring/src/org/netbeans/modules/xml/refactoring/impl/Attic/GeneralChangeExecutor.java,v
 <--  GeneralChangeExecutor.java
new revision: 1.1.2.1.2.1; previous revision: 1.1.2.1
/cvs/xml/refactoring/src/org/netbeans/modules/xml/refactoring/impl/Attic/RefactoringUtil.java,v
 <--  RefactoringUtil.java
new revision: 1.1.2.13.2.2; previous revision: 1.1.2.13.2.1
/cvs/xml/refactoring/src/org/netbeans/modules/xml/refactoring/impl/Attic/Bundle.properties,v
 <--  Bundle.properties
new revision: 1.1.2.11.2.2; previous revision: 1.1.2.11.2.1
/cvs/xml/schema/core/test/unit/src/org/netbeans/modules/xml/schema/core/Attic/SchemaRefactoringTest.java,v
 <--  SchemaRefactoringTest.java
new revision: 1.1.2.15.2.4; previous revision: 1.1.2.15.2.3
Comment 2 Nam Nguyen 2006-10-10 16:03:31 UTC 
Created attachment 35082 [details]
fix
Comment 3 Nam Nguyen 2006-10-10 22:53:41 UTC 
A much smaller change is needed.
We only need to make sure we detach the RefactoringManager listener from old
usage set together with clear old undo support before processing the next
refactoring.
Comment 4 Nam Nguyen 2006-10-10 22:55:05 UTC 
Created attachment 35097 [details]
A simpler and more effective fix.
Comment 5 Nam Nguyen 2006-10-10 22:55:45 UTC 
Fix committed to release55.
Comment 6 Nam Nguyen 2006-10-11 01:23:14 UTC 
*** Issue 86899 has been marked as a duplicate of this issue. ***
Comment 7 Ivan Sidorkin 2006-10-12 10:15:27 UTC 
verified in 061011_1