There is a problem with the order of notifications are generated by Undo transaction. The transaction can contain a set
of changes, which are processed by a XDM model to synchronize a XAM with sources.
New prefix declaration can be required to be added, when the user creates something new in the model. It usually is
doing automatically and in the same transaction with the main changes. So such a transaction, after its completion,
contains new prefix declaration and some other changes both.
If the user decides undo such changes, the XAM based model has to remove the prefix declaration and other changes. But
it is important the prefix declaration is removed at the end of transaction because such a prefix declaration is
required to delete other elements/attributes. But XDM generates undo events according to position of the modified object
in sources and particularly from top to bottom.
Such behavior of the XDM model leads to impossibility to delete some changes and as a result the XAM and XDM models
The problem has been found quite long time ago. For example, we faced it when working with BPEL extensions (see issue
#130777). But only a workaround was applied so far and it covers only BPEL extensions cases.
I'm going to prepare a test project and instruction to reproduce the problem a bit later.
This s defect indeed.
Fixed in trunk
It didn't require significant modifications because most of infrastructure already had presented in XDM model.
Fix is reopened because if caused another issue #186068 which looks more serious.
It's necessary to find another way of fixing.
Changes pushed to trunk http://hg.netbeans.org/main/rev/b5ca60f8018b
A few API modifications was required to do to fix the issue.
See issue #186266
Integrated into 'main-golden', will be available in build *201005260001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Log: #166177 - Undo/Redo transactions can lead to losing synchronization because of prefix declaration
The issue is fixed in trunk and it definitely worth to be added to patch.
It's necessary to BE CAREFUL with automatic migration of the issue (trunk --> release6.9.1)
The method XDMListener.prepareChangeInfo(...) was deleted in trunk during fixing the issue. But it exists in release69 branch and it's visible through module's API.
I've just returned the method back in trunk http://hg.netbeans.org/main/rev/b1b92368451b
It's necessary to comply binary compatibility with 6.9.
So the method has to remain in 6.9.1 as well!
correct status whiteboard term
Transplanted into release691 repository as f511be5a98a1
Please verify this issue in trunk.
Verified in trunk with JUnit tests and manually.
Migrated all relevant changes from trunk to release691 http://hg.netbeans.org/release691/rev/c3fc05c2e74c
Integrated into 'main-golden', will be available in build *201006190001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Log: Add missing version dependency (issue #166177)
any chance to get the promised steps to reproduce so that i could verify in 6.9.1 build? Thanks in advance.
Regarding seteps to reproduce:
It's necessary to have a XAM transaction, which creates a new prefix declaration together with an XML expression, which usese the NS declaration. It's the main problem. There are some examples in BPEL, but I can't provide exact one because I'm on vacation right now.
Then undo should remove the NS declaration and the expression both. Only the ns declaration had removed before the fix.