Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » CDO and ECrossReferenceAdapter
CDO and ECrossReferenceAdapter [message #422820] Tue, 16 September 2008 12:01 Go to next message
Paul Richardson is currently offline Paul RichardsonFriend
Messages: 33
Registered: July 2009
Member
Hi folks,

Happily have CDO working as the backend resource store for our
repository. Have hit on a problem though.

A "Project" in the CDO repository consists of a ProjectModel containing
uncontained references to folders and contained references to elements.
Likewise, each folder has a contained reference to elements. Thus:

ProjectModel
|_ Element1
|_ Folder1
|_Element2

Folders are persisted in their own resources and have no reference back
to this projectmodel.

The ProjectModel has a couple of attributes that I need to interrogate,
regardless of my location in the tree. As a consequence, I added an
ECrossReferenceAdapter to the resource set of my editing domain:

editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
commandStack);
editingDomain.getResourceSet().eAdapters().add(crossReferenc eAdapter);

This means that I can navigate back up the tree from any folder and find
the ProjectModel and thus retrieve its attributes. This has worked fine
with XMI resources stored on the filesystem yet has consistently failed
when CDO is introduced. The stacktrace is at the end of the message.

Essentially, it seems the a NP exception is occurring on account of the
fact that the CDOResource lacks an EStore. Given its a CDO Resource I
would imagine it has a CDOStore instead? Is there anything I can do to
fix this error. I can get around it by adding transient references to
the ProjectModel from each Folder but I was hoping to avoid that.

Any help much appreciated.

Regards

PGR


class java.lang.NullPointerException
Message:null

org.eclipse.emf.ecore.impl.EStoreEObjectImpl.eDynamicIsSet(E StoreEObjectImpl.java:688)
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1250)
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1235)
org.eclipse.emf.internal.cdo.CDOObjectImpl.eIsSet(CDOObjectI mpl.java:492)
org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:407)
org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:697)
org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:674)
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:646)
org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:6 26)
org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:129)
org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
org.eclipse.emf.ecore.util.ECrossReferenceAdapter.handleCont ainment(ECrossReferenceAdapter.java:585)
org.eclipse.emf.ecore.util.ECrossReferenceAdapter.selfAdapt( ECrossReferenceAdapter.java:542)
org.eclipse.emf.ecore.util.ECrossReferenceAdapter.notifyChan ged(ECrossReferenceAdapter.java:430)
org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:247)
org.eclipse.emf.common.notify.impl.NotifyingListImpl.dispatc hNotification(NotifyingListImpl.java:267)
org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:300)
org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:6 26)
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.createRe source(ResourceSetImpl.java:426)
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandCr eateResource(ResourceSetImpl.java:239)
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:391)
org.eclipse.emf.internal.cdo.CDOViewImpl.getResource(CDOView Impl.java:222)


---

RepositoryConnectionImpl is my model object which handles the connection
to a CDO Resource. The code used here is, where transaction has been
created with the editingdomain resourceset as a parameter:

CDOResourceImpl projectModelResource = (CDOResourceImpl)
transaction.getResource(uri.path());

---

isse.project.impl.RepositoryConnectionImpl.connect(Repositor yConnectionImpl.java:241)

isse.model.project.actions.ConnectAction.performAction(Conne ctAction.java:82)
Re: CDO and ECrossReferenceAdapter [message #422823 is a reply to message #422820] Tue, 16 September 2008 13:42 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Hi PhantomJinx!

Which version of CDO you are using ?
I'm asking that because in version 2.0 we've made some effort to align CDO
to EMF.
We've made some change to how objects/resources are created.


E.g.:
246705: Support containment proxies
https://bugs.eclipse.org/bugs/show_bug.cgi?id=246705
246630: Shouldn't override hasProxies and use default behavior in
CDOObjectImpl.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=246630

I will try to create a testcase to see if it fixes the problems.

Simon


"phantomjinx" <p.g.richardson@phantomjinx.co.uk> a
Re: CDO and ECrossReferenceAdapter [message #422824 is a reply to message #422823] Tue, 16 September 2008 13:47 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6468
Registered: July 2009
Senior Member
Simon McDuff schrieb:
> Hi PhantomJinx!
>
> Which version of CDO you are using ?
> I'm asking that because in version 2.0 we've made some effort to align CDO
> to EMF.
> We've made some change to how objects/resources are created.
>
>
> E.g.:
> 246705: Support containment proxies
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=246705
> 246630: Shouldn't override hasProxies and use default behavior in
> CDOObjectImpl.
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=246630
>
I have the feeling this one is more related (depending on what you want
to achieve with the adapter):

247141: Create a lazy self-attaching adapter for CDOObject
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247141

Cheers
/Eike


> I will try to create a testcase to see if it fixes the problems.
>
> Simon
>
>
> "phantomjinx" <p.g.richardson@phantomjinx.co.uk> a écrit dans le message de
> news: gao77f$4ko$1@build.eclipse.org...
>
>> Hi folks,
>>
>> Happily have CDO working as the backend resource store for our repository.
>> Have hit on a problem though.
>>
>> A "Project" in the CDO repository consists of a ProjectModel containing
>> uncontained references to folders and contained references to elements.
>> Likewise, each folder has a contained reference to elements. Thus:
>>
>> ProjectModel
>> |_ Element1
>> |_ Folder1
>> |_Element2
>>
>> Folders are persisted in their own resources and have no reference back to
>> this projectmodel.
>>
>> The ProjectModel has a couple of attributes that I need to interrogate,
>> regardless of my location in the tree. As a consequence, I added an
>> ECrossReferenceAdapter to the resource set of my editing domain:
>>
>> editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
>> commandStack);
>> editingDomain.getResourceSet().eAdapters().add(crossReferenc eAdapter);
>>
>> This means that I can navigate back up the tree from any folder and find
>> the ProjectModel and thus retrieve its attributes. This has worked fine
>> with XMI resources stored on the filesystem yet has consistently failed
>> when CDO is introduced. The stacktrace is at the end of the message.
>>
>> Essentially, it seems the a NP exception is occurring on account of the
>> fact that the CDOResource lacks an EStore. Given its a CDO Resource I
>> would imagine it has a CDOStore instead? Is there anything I can do to fix
>> this error. I can get around it by adding transient references to the
>> ProjectModel from each Folder but I was hoping to avoid that.
>>
>> Any help much appreciated.
>>
>> Regards
>>
>> PGR
>>
>>
>> class java.lang.NullPointerException
>> Message:null
>>
>> org.eclipse.emf.ecore.impl.EStoreEObjectImpl.eDynamicIsSet(E StoreEObjectImpl.java:688)
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1250)
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1235)
>> org.eclipse.emf.internal.cdo.CDOObjectImpl.eIsSet(CDOObjectI mpl.java:492)
>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:407)
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:697)
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:674)
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>> org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:646)
>> org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:6 26)
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:129)
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.handleCont ainment(ECrossReferenceAdapter.java:585)
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.selfAdapt( ECrossReferenceAdapter.java:542)
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.notifyChan ged(ECrossReferenceAdapter.java:430)
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:247)
>> org.eclipse.emf.common.notify.impl.NotifyingListImpl.dispatc hNotification(NotifyingListImpl.java:267)
>> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:300)
>> org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:6 26)
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.createRe source(ResourceSetImpl.java:426)
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandCr eateResource(ResourceSetImpl.java:239)
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:391)
>> org.eclipse.emf.internal.cdo.CDOViewImpl.getResource(CDOView Impl.java:222)
>>
>> ---
>>
>> RepositoryConnectionImpl is my model object which handles the connection
>> to a CDO Resource. The code used here is, where transaction has been
>> created with the editingdomain resourceset as a parameter:
>>
>> CDOResourceImpl projectModelResource = (CDOResourceImpl)
>> transaction.getResource(uri.path());
>>
>> ---
>>
>> isse.project.impl.RepositoryConnectionImpl.connect(Repositor yConnectionImpl.java:241)
>> isse.model.project.actions.ConnectAction.performAction(Conne ctAction.java:82)
>>
>
>
>


Re: CDO and ECrossReferenceAdapter [message #422825 is a reply to message #422823] Tue, 16 September 2008 13:57 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Based on the stackTrace I pretty sure you used 1.0.0 or and old of HEAD.

Basically, now it should work.

Before the way we were created resource was tricky. After CDOResourceFactory
was called, the resource was not ready to be used. It is why you didn't any
eStore associate to it. If you had an adapter and used it.. it was
failing....

Now this changed! In HEAD.

My testcases that I added was working!! :-)

If this is still not working for you(I used a simple adapter) (with HEAD)
please let us know.

Simon

"Simon McDuff" <smcduff@hotmail.com> a
Re: CDO and ECrossReferenceAdapter [message #422826 is a reply to message #422824] Tue, 16 September 2008 13:59 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
What he will find out that it should fetch objects in memory....so it should
work but not lazily! :-)


"Eike Stepper" <stepper@esc-net.de> a
Re: CDO and ECrossReferenceAdapter [message #422851 is a reply to message #422825] Wed, 17 September 2008 09:04 Go to previous message
Paul Richardson is currently offline Paul RichardsonFriend
Messages: 33
Registered: July 2009
Member
Hi Simon,

Certainly am using 1.0.0 so will checkout HEAD and see how it goes.

Many thanks.

PGR

Simon McDuff wrote:
> Based on the stackTrace I pretty sure you used 1.0.0 or and old of HEAD.
>
> Basically, now it should work.
>
> Before the way we were created resource was tricky. After CDOResourceFactory
> was called, the resource was not ready to be used. It is why you didn't any
> eStore associate to it. If you had an adapter and used it.. it was
> failing....
>
> Now this changed! In HEAD.
>
> My testcases that I added was working!! :-)
>
> If this is still not working for you(I used a simple adapter) (with HEAD)
> please let us know.
>
> Simon
>
> "Simon McDuff" <smcduff@hotmail.com> a écrit dans le message de news:
> gaod56$sh$1@build.eclipse.org...
>> Hi PhantomJinx!
>>
>> Which version of CDO you are using ?
>> I'm asking that because in version 2.0 we've made some effort to align CDO
>> to EMF.
>> We've made some change to how objects/resources are created.
>>
>>
>> E.g.:
>> 246705: Support containment proxies
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=246705
>> 246630: Shouldn't override hasProxies and use default behavior in
>> CDOObjectImpl.
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=246630
>>
>> I will try to create a testcase to see if it fixes the problems.
>>
>> Simon
>>
>>
>> "phantomjinx" <p.g.richardson@phantomjinx.co.uk> a écrit dans le message
>> de news: gao77f$4ko$1@build.eclipse.org...
>>> Hi folks,
>>>
>>> Happily have CDO working as the backend resource store for our
>>> repository. Have hit on a problem though.
>>>
>>> A "Project" in the CDO repository consists of a ProjectModel containing
>>> uncontained references to folders and contained references to elements.
>>> Likewise, each folder has a contained reference to elements. Thus:
>>>
>>> ProjectModel
>>> |_ Element1
>>> |_ Folder1
>>> |_Element2
>>>
>>> Folders are persisted in their own resources and have no reference back
>>> to this projectmodel.
>>>
>>> The ProjectModel has a couple of attributes that I need to interrogate,
>>> regardless of my location in the tree. As a consequence, I added an
>>> ECrossReferenceAdapter to the resource set of my editing domain:
>>>
>>> editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
>>> commandStack);
>>> editingDomain.getResourceSet().eAdapters().add(crossReferenc eAdapter);
>>>
>>> This means that I can navigate back up the tree from any folder and find
>>> the ProjectModel and thus retrieve its attributes. This has worked fine
>>> with XMI resources stored on the filesystem yet has consistently failed
>>> when CDO is introduced. The stacktrace is at the end of the message.
>>>
>>> Essentially, it seems the a NP exception is occurring on account of the
>>> fact that the CDOResource lacks an EStore. Given its a CDO Resource I
>>> would imagine it has a CDOStore instead? Is there anything I can do to
>>> fix this error. I can get around it by adding transient references to the
>>> ProjectModel from each Folder but I was hoping to avoid that.
>>>
>>> Any help much appreciated.
>>>
>>> Regards
>>>
>>> PGR
>>>
>>>
>>> class java.lang.NullPointerException
>>> Message:null
>>>
>>> org.eclipse.emf.ecore.impl.EStoreEObjectImpl.eDynamicIsSet(E StoreEObjectImpl.java:688)
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1250)
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObj ectImpl.java:1235)
>>> org.eclipse.emf.internal.cdo.CDOObjectImpl.eIsSet(CDOObjectI mpl.java:492)
>>> org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImp l.hasNext(EContentsEList.java:407)
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:697)
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.setTarget( ECrossReferenceAdapter.java:674)
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.didAdd(BasicNotifierImpl.java:77)
>>> org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:646)
>>> org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:6 26)
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapte rList.add(BasicNotifierImpl.java:129)
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.addAdapter (ECrossReferenceAdapter.java:819)
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.handleCont ainment(ECrossReferenceAdapter.java:585)
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.selfAdapt( ECrossReferenceAdapter.java:542)
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter.notifyChan ged(ECrossReferenceAdapter.java:430)
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:247)
>>> org.eclipse.emf.common.notify.impl.NotifyingListImpl.dispatc hNotification(NotifyingListImpl.java:267)
>>> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:300)
>>> org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:6 26)
>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.createRe source(ResourceSetImpl.java:426)
>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandCr eateResource(ResourceSetImpl.java:239)
>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:391)
>>> org.eclipse.emf.internal.cdo.CDOViewImpl.getResource(CDOView Impl.java:222)
>>>
>>> ---
>>>
>>> RepositoryConnectionImpl is my model object which handles the connection
>>> to a CDO Resource. The code used here is, where transaction has been
>>> created with the editingdomain resourceset as a parameter:
>>>
>>> CDOResourceImpl projectModelResource = (CDOResourceImpl)
>>> transaction.getResource(uri.path());
>>>
>>> ---
>>>
>>> isse.project.impl.RepositoryConnectionImpl.connect(Repositor yConnectionImpl.java:241)
>>> isse.model.project.actions.ConnectAction.performAction(Conne ctAction.java:82)
>>
>
>
Previous Topic:The mapping rule of xsd2ecore
Next Topic:LINQ for EMF, experience so far
Goto Forum:
  


Current Time: Sat Jan 25 10:27:51 GMT 2020

Powered by FUDForum. Page generated in 0.01825 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top