|Re: [CDO] CDOResource.eResource() creates an infinite loop in EMF EditingDomains [message #891782 is a reply to message #890796]
||Mon, 25 June 2012 22:12
| Paco Blanco
Registered: June 2012
CDOResources, including the root Resource, are persistent EObjects, hence must be contained in a Resource. For all "normal" CDOResourceNodes that are not contained in a CDOResourceFolder that is the (invisible) root resource.|
It is logical than a normal CDOResource (or CDOResource subFolder) return its CDOResource parent, included the "invisible" root resource. But for me it is not logical that the root parent container is not null.
So you can do CDOObject.eContainer().eContainer().eContainer().eContainer()... at infinitum because root CDOResource.eContainer() returns its own instance.
Have you tried to deploy the org.eclipse.emf.cdo.edit plugin? CDOResourceItemProvider has this method:
* Returns the parent of the argument CDOResource
* @since 2.0
public Object getParent(Object object)
CDOResource resource = (CDOResource)object;
No, I have not. Do you try to say to me that if I put this plugin and register (me or itself at plugin start) the CDO Adapter Factory (I do not have access to the exact class name now), my EMF Edit implementation maybe adapt to CDOResourceItemProvider and not to ItemProviderAdapter (I suppose standard adaptation class from EObject)?
My reasoning: when the execution manages CDOObject (not CDOResource), they are adapted to ItemProviderAdapter to provide getParent() and when execution gets a CDOResource object, it is adapted to CDOResourceItemProvider getParent() implementation.
It strikes me that CDOResourceFolderItemProvider.getParent(Object) should be moved up to CDOResourceNodeItemProvider in order to work with the new CDOFileResources. Can you please submit a bugzilla?
I am very lazy to create an account in bugzilla buy tomorrow I expect to do it
[Updated on: Mon, 25 June 2012 22:42]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.02718 seconds