Community
Participate
Working Groups
(See bug 234191 for more information) The distillation of the problem is this: - We have an EMF resource loaded for the document in the currently open editor. - User deletes all text (or at least enough text to make document unusable for current EMF model) - EMF resource gets unloaded - EMF2DOM renderer deregisters with xml model. (At this point it looks like there is nothing that can be done. I don't see how the EMF2DOM renderer can be reassociated with the XML model in the given code without actively calling the EMF resource to be reloaded.) - User "undoes" previous action (note that the file has not been saved as of yet) - No reconnection of renderer with XML model occurs, EMF model does not get reloaded (from Chuck Bridgham) Quick glance tells me the EMF2DOM shouldn't unload the EMF Resource quite yet, but should wait for a save or disposal of the XML model. The reason the EMF2DOM isn't being notified is it has probably disconnected its listener from the SSEModel - effectively disposed.... Biggest problem with this theory though is when the user recreates the root node.... If it doesn't match the EMF Resource, then a new EMF Resource needs to be reloaded, but if the listener is still active, this could be detected. In any case this will be a challenging problem for sure.
For additional clarification, if you break the syntax of the root node in any way you will run into this problem. Simply deleting a character of the element or accidentally removing a '>' could get you into this state.
Assigning this to Chuck for initial investigation. I know some work has been done in this area- is it still a problem in WTP 3.2?
Yes. This problem still exists in the latest 3.2 code, and is probably one of the worst bugs currently in Dali. I confirmed this today by testing a file revert after a trivial modification on a valid persistence.xml file. The result is loss of all model and editing capability related to this root artifact until the workspace is restarted or a project Clean... is performed.
Closing an edited file without saving causes the same issues. Any progress update for fixing this bug?
Since this blocks a P1 bug, this should be P1 too. We'll need to at least address, if not fix, for M4. Thanks,
Hi David, I accept this hotbug, and will mark it as such, but I disagree with marking for M4 the day our milestone shutdown week starts. I'll plan on addressing this in M5
Ok, thanks Chuck. I was hoping it could at least be investigated in the off chance it was an easy fix. Thanks.
working on solution.....
Created attachment 156743 [details] patch Here is a fix, that ensures this only disconnects/unloads the resource on a "REVERT", and ignores all other changes where the header XML has changed. I tested this, and it works for me...
I've heard this is very very important to get into this week's build to provide adequate testing before M5 .... so, I'm releasing. Test well! (And feel free to revert if I heard wrong :)
Created attachment 156852 [details] Patch to dali code I did see in the case of revert, that when the EMF Resource must be unloaded, that the dali model api doesn't react, and "refresh" the model by dumping and recreating a new EMFResource. this is the pattern that other listeners follow, or at least remove the underlying EMF model, and lazily load when needed. I'm not claiming this code is very good or correct (I did get some errors when testing) - but it demonstrates the reaction that is appropriate when such an event is caught.
Re-opening because additional api is required to react to "revert" only events Adding additional patch
Created attachment 157002 [details] revert patch Adding api on translator resources allowed to call "isReverting()"
Created attachment 157003 [details] combined wst patch (with addition) I think there was one bit of code missing from the latest patch. There was no isReverting() added to EMF2DOMSSERenderer to return its actual flag, so as a result isReverting() would *always* be false. I've combined the two above wst patches with this small change and attached that here.
Dropping to P2 and moving to WTP 3.2 M6 - there is a little more to do, but the biggest problem is now fixed.
Has this not been checked in yet?
Checking in wst.common code.... Adding xml.core patch... and transferring to SSE tools to commit rest
Created attachment 159133 [details] patch Only patch to org.eclipse.wst.xml.core left...
I've released the patch in comment #18 for this week's I-build, so will mark as fixed. Please re-open if I have misunderstood, and there's more to be done.
Nope, looks good. Thanks. I've tested this with our use of the API and it seems to solve most if not all of our problems. I'll open a different item if something else/related pops up.
verified fixed in WTP S-3.2.0M7-20100429210436
