|
|
| Re: CDO and ECrossReferenceAdapter [message #422824 is a reply to message #422823] |
Tue, 16 September 2008 13:47   |
|
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)
>>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
| Re: CDO and ECrossReferenceAdapter [message #422851 is a reply to message #422825] |
Wed, 17 September 2008 09:04 |
 Paul Richardson
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)
>>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03920 seconds
] 
Search
Help
Register
Login
Home
