Bugzilla – Full Text Bug Listing
| Summary: | Mismatch between EMF and CDO featureID values | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Stephane fournier <stephane.fournier> | ||||||
| Component: | cdo.core | Assignee: | Eike Stepper <stepper> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | Ed.Merks, smcduff, stepper | ||||||
| Version: | 2.0 | Flags: | stepper:
galileo+
|
||||||
| Target Milestone: | M7 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Stephane fournier
I played around with this problem and talked to Ed, too. We can't change the order or values of the generated featureID constants because EClassImpl::getFeatureID(EStructuralFeature) relies on this order ;-( The start of this particular problem was the introduction of the CDOResourceNode super class which adds 3 features. We could turn the features intoEOperations and implement them in *both* subclasses. That would solve the mismatch with EMF but introduce potential for notification mismatch with the "virtual" CDOResourceNode features. Before I start to play with such a workaround I'd like to discuss how we can get rid of the "CDOResource is an EObject" curse... The workaround you suggested seems not trivial. Could you just change the notification event feature id in the CDOResourceImpl.setLoaded(boolean) method to Resource.RESOURCE__IS_LOADED ? With that value, it runs well for me. I've forgotten one thing :
CDOResourceImpl.setLoaded(boolean) returns a Notification that is not sent.
Could you send it in the CDOREsourceImpl.load(Map<?, ?> options) method.
Notification notification = setLoaded(true);
if (notification != null) {
eNotify(notification);
}
With that, CDO resource runs with Transaction Editing Domain. Without that, TED framework does not considered the CDOResource as loaded see different posts in the EMF newsgroup.
Stephane.
I played around with this problem and talked to Ed, too. We can't change the order or values of the generated featureID constants because EClassImpl::getFeatureID(EStructuralFeature) relies on this order ;-( The start of this particular problem was the introduction of the CDOResourceNode super class which adds 3 features. We could turn the features intoEOperations and implement them in *both* subclasses. That would solve the mismatch with EMF but introduce potential for notification mismatch with the "virtual" CDOResourceNode features. Before I start to play with such a workaround I'd like to discuss how we can get rid of the "CDOResource is an EObject" curse... Stephane, Can you come up with a patch? As I told you, at office I can not create a real patch as you expect. Nevertheless, I can send you a zip file with the CDO projects I modified. I put TODO task with bugzilla url, so it is easy to find the fixes. Please find attached a zip file that contains different fixes I made accroding the bugzilla I filed following the different posts in the newsgroup. For instance, this bug has a task named : FIX https://bugs.eclipse.org/bugs/show_bug.cgi?id=265136 in CDOResourceImpl.java. Created attachment 130361 [details] Contains different CDO bug fixes That zip file contains bug fixes for : - https://bugs.eclipse.org/bugs/show_bug.cgi?id=265136 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=269787 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=269789 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=269793 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=270139 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=270395 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=270415 Oh, what fun! ;-) I really hope that the foundation makes progress on support for git or so... Created attachment 130424 [details]
Patch
I've just made a real patch.
It should be easier to test it.
Hi Eike, Did you manage the path ? Sorry I did even not have the time to come to this issue again. Build issues have just taken 2 days ;-( I can imagine that this solution satisfies some adapters (those that use the feature id only to query the notification but not to access the object reflectively). But certainly this is not an ideal solution either since adapters that use the feature id of the notification to reflectively access the changed feature in the object will be broken. This can only be solved by removing the inheritance relation between CDOResource and EObject ;-( Committed to HEAD. What about the other attached zip? Did you create patches for the single bugs you addressed there? Hi Eike, You fixed most of the bugs I reported :) Status for the 3 remaining bugs: 1) I've just released a patch for https://bugs.eclipse.org/bugs/show_bug.cgi?id=270415 :) 2) https://bugs.eclipse.org/bugs/show_bug.cgi?id=269789, you suggested something, I let you implement it. 3)https://bugs.eclipse.org/bugs/show_bug.cgi?id=269793, I did find time to test without my patch. Toi be honest, I will test again with CDO 2.0.0 M7. Stéphane. Fix available in EMF CDO 2.0.0M7 Generally available. |