Home » Modeling » EMF » [CDO] ExtendedLibrary sample with CDO ?
| [CDO] ExtendedLibrary sample with CDO ? [message #422670] |
Fri, 12 September 2008 10:02  |
Eclipse User |
|
|
|
Hi,
Does anyone try to wire the Extended Library Editor (the one from EMF
examples) with CDO server ?
I'm not using the CDO session views.
I made some changes ExtendedLibrary editor to connect it to a CDO server,
open a session, get a transaction and create a cdo resource.
Problems raise when I try to add a new library with a writer.
All created objects seem to be transient. When debugging
CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this) always
answers true. Is it normal ?
When I commit the transaction, that fails with this message :
[ERROR] SQL Exception: The statement was aborted because it would have
caused a duplicate key value in a unique or primary key constraint or
unique index identified by 'CDORESOURCE_IDX0' defined on 'CDORESOURCE'.
Before I commit the transaction, I have no exception in eclipse log file.
N.B : Extended Library editor runs with an editing domain which is an EMF
Transactional one.
Does anyone have an idea ?
Stephane.
|
|
| |
| Re: [CDO] ExtendedLibrary sample with CDO ? [message #422679 is a reply to message #422674] |
Fri, 12 September 2008 11:29  |
| Eclipse User |
|
|
|
Hi Eike,
Yes, I have generated the Extended Library model with changes in the
genmodel as mentionned in the "Preparing EMF Models for CDO" article.
To create a resource, I'm using transaction.createResource(path) method. I
have moved to getOrCreateResource() method.
Once, the resource is created, I add it to a resource set owned by a
transactional editing domain.
Now, at save time, I got this exception stack :
java.lang.IllegalStateException: Failing event COMMIT in state TRANSIENT
for CDOResource@oid1
(data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
at
org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
at
org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
at
org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
at
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
at
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
My editor was already working with a transactional editing domain. I try
CDO to get a multi-user capability on my existing editor.
This editor is a GMF one that only works with a transational editing
domain.
My idea was to open a CDO transaction when the editor is opening. After
every save operation, I would like to commit the CDO transaction to really
flush data to the database.
Between save operations, my transactional editing domain listens to model
changes.
Stephane.
Eike Stepper wrote:
> Stéphane Fournier schrieb:
>> Hi,
>>
>> Does anyone try to wire the Extended Library Editor (the one from EMF
>> examples) with CDO server ?
>>
>> I'm not using the CDO session views.
>> I made some changes ExtendedLibrary editor to connect it to a CDO
>> server, open a session, get a transaction and create a cdo resource.
>>
>> Problems raise when I try to add a new library with a writer.
>>
>> All created objects seem to be transient. When debugging
>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>> always answers true. Is it normal ?
> I see you're using CDOObjectImpl but just to be sure: Did you regenerate
> the Library model after migrating the genmodel to CDO?
> Usually CDOObjects are TANSIENT as long as they're not attached to a
> CDOTransaction. This is also true for CDOResource (which is a CDOObject,
> too). How did you create the CDOResource?
> The best way is transaction.createResource(path). If objects are then
> attached to other objects that are already attached, the new objects
> will also transition from TRANSIENT to NEW.
>>
>> When I commit the transaction, that fails with this message :
>> [ERROR] SQL Exception: The statement was aborted because it would have
>> caused a duplicate key value in a unique or primary key constraint or
>> unique index identified by 'CDORESOURCE_IDX0' defined on 'CDORESOURCE'.
> Looks as if a resource with that path (i.e. URI) is already stored in
> the repository.
> Either clear your database from previous attempts or use a different
> resourcepath or call transaction.getOrCreateResource(path).
>> Before I commit the transaction, I have no exception in eclipse log file.
>>
>> N.B : Extended Library editor runs with an editing domain which is an
>> EMF Transactional one.
> That's (IMHO) generally not a good idea!
> Why do you add a second transactional layer on top of CDO?
> Cheers
> /Eike
|
|
|
| Re: [CDO] ExtendedLibrary sample with CDO ? [message #422682 is a reply to message #422679] |
Fri, 12 September 2008 11:42 |
| Eclipse User |
|
|
|
Stéphane Fournier schrieb:
> Hi Eike,
>
> Yes, I have generated the Extended Library model with changes in the
> genmodel as mentionned in the "Preparing EMF Models for CDO" article.
>
> To create a resource, I'm using transaction.createResource(path)
> method. I have moved to getOrCreateResource() method. Once, the
> resource is created, I add it to a resource set owned by a
> transactional editing domain.
Ah! That's not allowed! Because ResourceSet.resources is like a
containment reference it's like a detach from the CDOTransaction!
The best thing you can do is not using EMF Transaction (sorry
Christian!) on top of CDO.
The second best thing you could try is:
1) Get the ResourceSet out of the TransactionalEditingDomain
2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead of
creating a new resource set
>
> Now, at save time, I got this exception stack :
> java.lang.IllegalStateException: Failing event COMMIT in state
> TRANSIENT for CDOResource@oid1
> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>
> at
> org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>
> at
> org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>
> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>
> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>
> at
> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>
>
>
> My editor was already working with a transactional editing domain. I
> try CDO to get a multi-user capability on my existing editor. This
> editor is a GMF one that only works with a transational editing domain.
> My idea was to open a CDO transaction when the editor is opening.
> After every save operation, I would like to commit the CDO transaction
> to really flush data to the database.
> Between save operations, my transactional editing domain listens to
> model changes.
Many users already asked for compatibility with GMF so I'm very
interested in your results. Please give feedback! ;-)
Cheers
/Eike
>
>
> Stephane.
>
> Eike Stepper wrote:
>
>> Stéphane Fournier schrieb:
>>> Hi,
>>>
>>> Does anyone try to wire the Extended Library Editor (the one from
>>> EMF examples) with CDO server ?
>>>
>>> I'm not using the CDO session views.
>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>> server, open a session, get a transaction and create a cdo resource.
>>>
>>> Problems raise when I try to add a new library with a writer.
>>>
>>> All created objects seem to be transient. When debugging
>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>> always answers true. Is it normal ?
>> I see you're using CDOObjectImpl but just to be sure: Did you
>> regenerate the Library model after migrating the genmodel to CDO?
>
>> Usually CDOObjects are TANSIENT as long as they're not attached to a
>> CDOTransaction. This is also true for CDOResource (which is a
>> CDOObject, too). How did you create the CDOResource?
>
>> The best way is transaction.createResource(path). If objects are then
>> attached to other objects that are already attached, the new objects
>> will also transition from TRANSIENT to NEW.
>
>>>
>>> When I commit the transaction, that fails with this message :
>>> [ERROR] SQL Exception: The statement was aborted because it would
>>> have caused a duplicate key value in a unique or primary key
>>> constraint or unique index identified by 'CDORESOURCE_IDX0' defined
>>> on 'CDORESOURCE'.
>> Looks as if a resource with that path (i.e. URI) is already stored in
>> the repository.
>> Either clear your database from previous attempts or use a different
>> resourcepath or call transaction.getOrCreateResource(path).
>
>>> Before I commit the transaction, I have no exception in eclipse log
>>> file.
>>>
>>> N.B : Extended Library editor runs with an editing domain which is
>>> an EMF Transactional one.
>> That's (IMHO) generally not a good idea!
>> Why do you add a second transactional layer on top of CDO?
>
>> Cheers
>> /Eike
>
>
|
|
|
| Re: [CDO] ExtendedLibrary sample with CDO ? [message #422685 is a reply to message #422682] |
Fri, 12 September 2008 12:11 |
| Eclipse User |
|
|
|
Eike Stepper wrote:
I tried what you suggested at 2).
Now, I got the exception below. I'm using the embbeded derby store.
Indeed, after the resource creation a log mentionned that Legacy system is
not available. What does it mean ?
Ok, to give you feedbacks to run editor based on CDO and EMF Transaction,
if I succeed ;)
Stephane.
org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy system
not available
at
org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
at
org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
at
org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
at
org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
at
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
at
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
at
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
at
org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
at org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
at
org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
at
org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
at
org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
at
org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
at
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
at
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
at
com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
> Stéphane Fournier schrieb:
>> Hi Eike,
>>
>> Yes, I have generated the Extended Library model with changes in the
>> genmodel as mentionned in the "Preparing EMF Models for CDO" article.
>>
>> To create a resource, I'm using transaction.createResource(path)
>> method. I have moved to getOrCreateResource() method. Once, the
>> resource is created, I add it to a resource set owned by a
>> transactional editing domain.
> Ah! That's not allowed! Because ResourceSet.resources is like a
> containment reference it's like a detach from the CDOTransaction!
> The best thing you can do is not using EMF Transaction (sorry
> Christian!) on top of CDO.
> The second best thing you could try is:
> 1) Get the ResourceSet out of the TransactionalEditingDomain
> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead of
> creating a new resource set
>>
>> Now, at save time, I got this exception stack :
>> java.lang.IllegalStateException: Failing event COMMIT in state
>> TRANSIENT for CDOResource@oid1
>> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>
>> at
>>
org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>>
>> at
>>
org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>>
>> at
>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>>
>> at
>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>>
>> at
>>
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>>
>>
>>
>> My editor was already working with a transactional editing domain. I
>> try CDO to get a multi-user capability on my existing editor. This
>> editor is a GMF one that only works with a transational editing domain.
>> My idea was to open a CDO transaction when the editor is opening.
>> After every save operation, I would like to commit the CDO transaction
>> to really flush data to the database.
>> Between save operations, my transactional editing domain listens to
>> model changes.
> Many users already asked for compatibility with GMF so I'm very
> interested in your results. Please give feedback! ;-)
> Cheers
> /Eike
>>
>>
>> Stephane.
>>
>> Eike Stepper wrote:
>>
>>> Stéphane Fournier schrieb:
>>>> Hi,
>>>>
>>>> Does anyone try to wire the Extended Library Editor (the one from
>>>> EMF examples) with CDO server ?
>>>>
>>>> I'm not using the CDO session views.
>>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>>> server, open a session, get a transaction and create a cdo resource.
>>>>
>>>> Problems raise when I try to add a new library with a writer.
>>>>
>>>> All created objects seem to be transient. When debugging
>>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>>> always answers true. Is it normal ?
>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>> regenerate the Library model after migrating the genmodel to CDO?
>>
>>> Usually CDOObjects are TANSIENT as long as they're not attached to a
>>> CDOTransaction. This is also true for CDOResource (which is a
>>> CDOObject, too). How did you create the CDOResource?
>>
>>> The best way is transaction.createResource(path). If objects are then
>>> attached to other objects that are already attached, the new objects
>>> will also transition from TRANSIENT to NEW.
>>
>>>>
>>>> When I commit the transaction, that fails with this message :
>>>> [ERROR] SQL Exception: The statement was aborted because it would
>>>> have caused a duplicate key value in a unique or primary key
>>>> constraint or unique index identified by 'CDORESOURCE_IDX0' defined
>>>> on 'CDORESOURCE'.
>>> Looks as if a resource with that path (i.e. URI) is already stored in
>>> the repository.
>>> Either clear your database from previous attempts or use a different
>>> resourcepath or call transaction.getOrCreateResource(path).
>>
>>>> Before I commit the transaction, I have no exception in eclipse log
>>>> file.
>>>>
>>>> N.B : Extended Library editor runs with an editing domain which is
>>>> an EMF Transactional one.
>>> That's (IMHO) generally not a good idea!
>>> Why do you add a second transactional layer on top of CDO?
>>
>>> Cheers
>>> /Eike
>>
>>
|
|
|
| Re: [CDO] ExtendedLibrary sample with CDO ? [message #422687 is a reply to message #422685] |
Fri, 12 September 2008 12:55 |
| Eclipse User |
|
|
|
Stéphane Fournier schrieb:
> Eike Stepper wrote:
>
> I tried what you suggested at 2).
> Now, I got the exception below. I'm using the embbeded derby store.
>
> Indeed, after the resource creation a log mentionned that Legacy
> system is not available. What does it mean ?
Usually an indication that you are trying to attach non-native objects
to a transaction (or a bug).
but from the stack trace I can see that you're not using a brand new CDO
source from HEAD.
Only yesterday we committed substantial changes. Can youplease re-test
with newest HEAD?
Cheers
/Eike
>
> Ok, to give you feedbacks to run editor based on CDO and EMF
> Transaction, if I succeed ;)
>
> Stephane.
>
> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
> system not available
> at
> org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
>
> at
> org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
>
> at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
> at
> org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
>
> at
> org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
>
> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
>
> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
>
> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>
> at
> org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>
> at
> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
> at
> org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>
> at
> org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>
> at
> org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>
> at
> org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>
> at
> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>
> at
> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>
> at
> com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>
>
>
>
>> Stéphane Fournier schrieb:
>>> Hi Eike,
>>>
>>> Yes, I have generated the Extended Library model with changes in the
>>> genmodel as mentionned in the "Preparing EMF Models for CDO" article.
>>>
>>> To create a resource, I'm using transaction.createResource(path)
>>> method. I have moved to getOrCreateResource() method. Once, the
>>> resource is created, I add it to a resource set owned by a
>>> transactional editing domain.
>> Ah! That's not allowed! Because ResourceSet.resources is like a
>> containment reference it's like a detach from the CDOTransaction!
>
>> The best thing you can do is not using EMF Transaction (sorry
>> Christian!) on top of CDO.
>
>> The second best thing you could try is:
>> 1) Get the ResourceSet out of the TransactionalEditingDomain
>> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead
>> of creating a new resource set
>
>
>>>
>>> Now, at save time, I got this exception stack :
>>> java.lang.IllegalStateException: Failing event COMMIT in state
>>> TRANSIENT for CDOResource@oid1
>>> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>>
>>> at
> org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>
>>>
>>> at
> org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>
>>>
>>> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>
>>>
>>> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>
>>>
>>> at
> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>
>>>
>>>
>>>
>>> My editor was already working with a transactional editing domain. I
>>> try CDO to get a multi-user capability on my existing editor. This
>>> editor is a GMF one that only works with a transational editing domain.
>>> My idea was to open a CDO transaction when the editor is opening.
>>> After every save operation, I would like to commit the CDO
>>> transaction to really flush data to the database.
>>> Between save operations, my transactional editing domain listens to
>>> model changes.
>> Many users already asked for compatibility with GMF so I'm very
>> interested in your results. Please give feedback! ;-)
>
>> Cheers
>> /Eike
>
>
>>>
>
>>>
>>> Stephane.
>>>
>>> Eike Stepper wrote:
>>>
>>>> Stéphane Fournier schrieb:
>>>>> Hi,
>>>>>
>>>>> Does anyone try to wire the Extended Library Editor (the one from
>>>>> EMF examples) with CDO server ?
>>>>>
>>>>> I'm not using the CDO session views.
>>>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>>>> server, open a session, get a transaction and create a cdo resource.
>>>>>
>>>>> Problems raise when I try to add a new library with a writer.
>>>>>
>>>>> All created objects seem to be transient. When debugging
>>>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>>>> always answers true. Is it normal ?
>>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>>> regenerate the Library model after migrating the genmodel to CDO?
>>>
>>>> Usually CDOObjects are TANSIENT as long as they're not attached to
>>>> a CDOTransaction. This is also true for CDOResource (which is a
>>>> CDOObject, too). How did you create the CDOResource?
>>>
>>>> The best way is transaction.createResource(path). If objects are
>>>> then attached to other objects that are already attached, the new
>>>> objects will also transition from TRANSIENT to NEW.
>>>
>>>>>
>>>>> When I commit the transaction, that fails with this message :
>>>>> [ERROR] SQL Exception: The statement was aborted because it would
>>>>> have caused a duplicate key value in a unique or primary key
>>>>> constraint or unique index identified by 'CDORESOURCE_IDX0'
>>>>> defined on 'CDORESOURCE'.
>>>> Looks as if a resource with that path (i.e. URI) is already stored
>>>> in the repository.
>>>> Either clear your database from previous attempts or use a
>>>> different resourcepath or call transaction.getOrCreateResource(path).
>>>
>>>>> Before I commit the transaction, I have no exception in eclipse
>>>>> log file.
>>>>>
>>>>> N.B : Extended Library editor runs with an editing domain which is
>>>>> an EMF Transactional one.
>>>> That's (IMHO) generally not a good idea!
>>>> Why do you add a second transactional layer on top of CDO?
>>>
>>>> Cheers
>>>> /Eike
>>>
>>>
>
>
|
|
|
| Re: [CDO] ExtendedLibrary sample with CDO ? [message #422696 is a reply to message #422687] |
Sat, 13 September 2008 15:53 |
| Eclipse User |
|
|
|
Ok Eike,
I'll check-out the latest release immediately.
I will test that on next Monday.
Stephane.
Eike Stepper wrote:
> Stéphane Fournier schrieb:
>> Eike Stepper wrote:
>>
>> I tried what you suggested at 2).
>> Now, I got the exception below. I'm using the embbeded derby store.
>>
>> Indeed, after the resource creation a log mentionned that Legacy
>> system is not available. What does it mean ?
> Usually an indication that you are trying to attach non-native objects
> to a transaction (or a bug).
> but from the stack trace I can see that you're not using a brand new CDO
> source from HEAD.
> Only yesterday we committed substantial changes. Can youplease re-test
> with newest HEAD?
> Cheers
> /Eike
>>
>> Ok, to give you feedbacks to run editor based on CDO and EMF
>> Transaction, if I succeed ;)
>>
>> Stephane.
>>
>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
>> system not available
>> at
>>
org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
>>
>> at
>>
org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
>>
>> at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
>> at
>>
org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
>>
>> at
>>
org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
>>
>> at
>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
>>
>> at
>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
>>
>> at
>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>>
>> at
>>
org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>>
>> at
>> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>> at
>>
org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>>
>> at
>>
org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>>
>> at
>>
org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>>
>> at
>>
org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>>
>> at
>>
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>>
>> at
>>
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>>
>> at
>>
com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>>
>>
>>
>>
>>> Stéphane Fournier schrieb:
>>>> Hi Eike,
>>>>
>>>> Yes, I have generated the Extended Library model with changes in the
>>>> genmodel as mentionned in the "Preparing EMF Models for CDO" article.
>>>>
>>>> To create a resource, I'm using transaction.createResource(path)
>>>> method. I have moved to getOrCreateResource() method. Once, the
>>>> resource is created, I add it to a resource set owned by a
>>>> transactional editing domain.
>>> Ah! That's not allowed! Because ResourceSet.resources is like a
>>> containment reference it's like a detach from the CDOTransaction!
>>
>>> The best thing you can do is not using EMF Transaction (sorry
>>> Christian!) on top of CDO.
>>
>>> The second best thing you could try is:
>>> 1) Get the ResourceSet out of the TransactionalEditingDomain
>>> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead
>>> of creating a new resource set
>>
>>
>>>>
>>>> Now, at save time, I got this exception stack :
>>>> java.lang.IllegalStateException: Failing event COMMIT in state
>>>> TRANSIENT for CDOResource@oid1
>>>>
(data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>>>
>>>> at
>>
org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>>
>>>>
>>>> at
>>
org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>>
>>>>
>>>> at
>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>>
>>>>
>>>> at
>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>>
>>>>
>>>> at
>>
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>>
>>>>
>>>>
>>>>
>>>> My editor was already working with a transactional editing domain. I
>>>> try CDO to get a multi-user capability on my existing editor. This
>>>> editor is a GMF one that only works with a transational editing domain.
>>>> My idea was to open a CDO transaction when the editor is opening.
>>>> After every save operation, I would like to commit the CDO
>>>> transaction to really flush data to the database.
>>>> Between save operations, my transactional editing domain listens to
>>>> model changes.
>>> Many users already asked for compatibility with GMF so I'm very
>>> interested in your results. Please give feedback! ;-)
>>
>>> Cheers
>>> /Eike
>>
>>
>>>>
>>
>>>>
>>>> Stephane.
>>>>
>>>> Eike Stepper wrote:
>>>>
>>>>> Stéphane Fournier schrieb:
>>>>>> Hi,
>>>>>>
>>>>>> Does anyone try to wire the Extended Library Editor (the one from
>>>>>> EMF examples) with CDO server ?
>>>>>>
>>>>>> I'm not using the CDO session views.
>>>>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>>>>> server, open a session, get a transaction and create a cdo resource.
>>>>>>
>>>>>> Problems raise when I try to add a new library with a writer.
>>>>>>
>>>>>> All created objects seem to be transient. When debugging
>>>>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>>>>> always answers true. Is it normal ?
>>>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>>>> regenerate the Library model after migrating the genmodel to CDO?
>>>>
>>>>> Usually CDOObjects are TANSIENT as long as they're not attached to
>>>>> a CDOTransaction. This is also true for CDOResource (which is a
>>>>> CDOObject, too). How did you create the CDOResource?
>>>>
>>>>> The best way is transaction.createResource(path). If objects are
>>>>> then attached to other objects that are already attached, the new
>>>>> objects will also transition from TRANSIENT to NEW.
>>>>
>>>>>>
>>>>>> When I commit the transaction, that fails with this message :
>>>>>> [ERROR] SQL Exception: The statement was aborted because it would
>>>>>> have caused a duplicate key value in a unique or primary key
>>>>>> constraint or unique index identified by 'CDORESOURCE_IDX0'
>>>>>> defined on 'CDORESOURCE'.
>>>>> Looks as if a resource with that path (i.e. URI) is already stored
>>>>> in the repository.
>>>>> Either clear your database from previous attempts or use a
>>>>> different resourcepath or call transaction.getOrCreateResource(path).
>>>>
>>>>>> Before I commit the transaction, I have no exception in eclipse
>>>>>> log file.
>>>>>>
>>>>>> N.B : Extended Library editor runs with an editing domain which is
>>>>>> an EMF Transactional one.
>>>>> That's (IMHO) generally not a good idea!
>>>>> Why do you add a second transactional layer on top of CDO?
>>>>
>>>>> Cheers
>>>>> /Eike
>>>>
>>>>
>>
>>
|
|
|
| Re: [CDO] ExtendedLibrary sample with CDO ? [message #422697 is a reply to message #422696] |
Sat, 13 September 2008 17:08 |
| Eclipse User |
|
|
|
Comments below.
At home, I can use thunderbird to read newsgroup ouf :)
Stéphane Fournier wrote:
> Ok Eike, I'll check-out the latest release immediately.
> I will test that on next Monday.
>
> Stephane.
>
Hi Eike,
I checked out the latest release and I tested again. I got the exception
below.
When you said :
Usually an indication that you are trying to attach non-native objects
to a transaction (or a bug).
What does it mean exactly "attach non-native objects"? EMF objects that
do not extend CDO objects ?
I'm sorry if the question is stupid, but to make sure I've correctly
understand.
Stephane.
Exception stack :
org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
system not available
at
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl$Persisten tContents.inverseAdd(CDOResourceImpl.java:567)
at
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:448)
at
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
at
org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
at org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
at
org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
at
org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
at
org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
at
org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
at
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
at
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
at
com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
at
com.thalesgroup.mde.tig.ef.command.TigCommandStack.doExecute (TigCommandStack.java:40)
at
org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:164)
at
org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:217)
at
org.eclipse.emf.edit.ui.action.StaticSelectionCommandAction. run(StaticSelectionCommandAction.java:232)
> Eike Stepper wrote:
>
>> Stéphane Fournier schrieb:
>>> Eike Stepper wrote:
>>>
>>> I tried what you suggested at 2).
>>> Now, I got the exception below. I'm using the embbeded derby store.
>>>
>>> Indeed, after the resource creation a log mentionned that Legacy
>>> system is not available. What does it mean ?
>> Usually an indication that you are trying to attach non-native objects
>> to a transaction (or a bug).
>> but from the stack trace I can see that you're not using a brand new
>> CDO source from HEAD.
>> Only yesterday we committed substantial changes. Can youplease re-test
>> with newest HEAD?
>
>> Cheers
>> /Eike
>
>>>
>>> Ok, to give you feedbacks to run editor based on CDO and EMF
>>> Transaction, if I succeed ;)
>>>
>>> Stephane.
>>>
>>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
>>> system not available
>>> at
> org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
>
>>>
>>> at
> org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
>
>>>
>>> at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
>>> at
> org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
>
>>>
>>> at
> org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
>
>>>
>>> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
>
>>>
>>> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
>
>>>
>>> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>
>>>
>>> at
> org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>
>>>
>>> at
>>> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>>> at
> org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>
>>>
>>> at
> org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>
>>>
>>> at
> org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>
>>>
>>> at
> org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>
>>>
>>> at
> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>
>>>
>>> at
> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>
>>>
>>> at
> com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>
>>>
>>>
>>>
>>>
>>>> Stéphane Fournier schrieb:
>>>>> Hi Eike,
>>>>>
>>>>> Yes, I have generated the Extended Library model with changes in
>>>>> the genmodel as mentionned in the "Preparing EMF Models for CDO"
>>>>> article.
>>>>>
>>>>> To create a resource, I'm using transaction.createResource(path)
>>>>> method. I have moved to getOrCreateResource() method. Once, the
>>>>> resource is created, I add it to a resource set owned by a
>>>>> transactional editing domain.
>>>> Ah! That's not allowed! Because ResourceSet.resources is like a
>>>> containment reference it's like a detach from the CDOTransaction!
>>>
>>>> The best thing you can do is not using EMF Transaction (sorry
>>>> Christian!) on top of CDO.
>>>
>>>> The second best thing you could try is:
>>>> 1) Get the ResourceSet out of the TransactionalEditingDomain
>>>> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead
>>>> of creating a new resource set
>>>
>>>
>>>>>
>>>>> Now, at save time, I got this exception stack :
>>>>> java.lang.IllegalStateException: Failing event COMMIT in state
>>>>> TRANSIENT for CDOResource@oid1
> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>>>>
>>>>> at
>>>
> org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>
>>>
>>>>>
>>>>>
>>>>>
>>>>> My editor was already working with a transactional editing domain.
>>>>> I try CDO to get a multi-user capability on my existing editor.
>>>>> This editor is a GMF one that only works with a transational
>>>>> editing domain.
>>>>> My idea was to open a CDO transaction when the editor is opening.
>>>>> After every save operation, I would like to commit the CDO
>>>>> transaction to really flush data to the database.
>>>>> Between save operations, my transactional editing domain listens to
>>>>> model changes.
>>>> Many users already asked for compatibility with GMF so I'm very
>>>> interested in your results. Please give feedback! ;-)
>>>
>>>> Cheers
>>>> /Eike
>>>
>>>
>>>>>
>>>
>>>>>
>>>>> Stephane.
>>>>>
>>>>> Eike Stepper wrote:
>>>>>
>>>>>> Stéphane Fournier schrieb:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Does anyone try to wire the Extended Library Editor (the one from
>>>>>>> EMF examples) with CDO server ?
>>>>>>>
>>>>>>> I'm not using the CDO session views.
>>>>>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>>>>>> server, open a session, get a transaction and create a cdo resource.
>>>>>>>
>>>>>>> Problems raise when I try to add a new library with a writer.
>>>>>>>
>>>>>>> All created objects seem to be transient. When debugging
>>>>>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>>>>>> always answers true. Is it normal ?
>>>>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>>>>> regenerate the Library model after migrating the genmodel to CDO?
>>>>>
>>>>>> Usually CDOObjects are TANSIENT as long as they're not attached to
>>>>>> a CDOTransaction. This is also true for CDOResource (which is a
>>>>>> CDOObject, too). How did you create the CDOResource?
>>>>>
>>>>>> The best way is transaction.createResource(path). If objects are
>>>>>> then attached to other objects that are already attached, the new
>>>>>> objects will also transition from TRANSIENT to NEW.
>>>>>
>>>>>>>
>>>>>>> When I commit the transaction, that fails with this message :
>>>>>>> [ERROR] SQL Exception: The statement was aborted because it would
>>>>>>> have caused a duplicate key value in a unique or primary key
>>>>>>> constraint or unique index identified by 'CDORESOURCE_IDX0'
>>>>>>> defined on 'CDORESOURCE'.
>>>>>> Looks as if a resource with that path (i.e. URI) is already stored
>>>>>> in the repository.
>>>>>> Either clear your database from previous attempts or use a
>>>>>> different resourcepath or call transaction.getOrCreateResource(path).
>>>>>
>>>>>>> Before I commit the transaction, I have no exception in eclipse
>>>>>>> log file.
>>>>>>>
>>>>>>> N.B : Extended Library editor runs with an editing domain which
>>>>>>> is an EMF Transactional one.
>>>>>> That's (IMHO) generally not a good idea!
>>>>>> Why do you add a second transactional layer on top of CDO?
>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>
>>>>>
>>>
>>>
>
>
|
|
| |
| Re: [CDO] ExtendedLibrary sample with CDO ? [message #422720 is a reply to message #422699] |
Mon, 15 September 2008 04:46 |
| Eclipse User |
|
|
|
Thanks folks for your support !
I missed the following point : to create the marker file (CDO.MF).
I can test again mixing CDO transactions and EMFT transactions.
Stephane.
Simon McDuff wrote:
> Hi Stephane,
> CDO do not support Legacy object anymore.
> I know Eike is currently working on a feature in EMF that will allow CDO to
> support easily legacy objects. In my opinion, it is a question of time
> (months. :-)).
> To be able to persist objects through CDO please follow this guideline:
>
http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO#Modify_ an_Existing_GenModel
> You just need to modify your genmodel.
> Simon
> "Stéphane Fournier" <stephane.fournier@netcourrier.com> a écrit dans le
> message de news: gaha51$145$1@build.eclipse.org...
>> Comments below.
>> At home, I can use thunderbird to read newsgroup ouf :)
>> Stéphane Fournier wrote:
>>> Ok Eike, I'll check-out the latest release immediately.
>>> I will test that on next Monday.
>>>
>>> Stephane.
>>>
>>
>> Hi Eike,
>> I checked out the latest release and I tested again. I got the exception
>> below.
>>
>> When you said :
>> Usually an indication that you are trying to attach non-native objects to
>> a transaction (or a bug).
>>
>> What does it mean exactly "attach non-native objects"? EMF objects that do
>> not extend CDO objects ?
>> I'm sorry if the question is stupid, but to make sure I've correctly
>> understand.
>>
>> Stephane.
>>
>>
>> Exception stack :
>>
>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy system
>> not available
>> at
>>
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl$Persisten tContents.inverseAdd(CDOResourceImpl.java:567)
>> at
>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:448)
>> at
>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>> at
>> org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>> at org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>> at
>>
org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>> at
>>
org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>> at
>>
org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>> at
>>
org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>> at
>>
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>> at
>>
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>> at
>>
com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>> at
>>
com.thalesgroup.mde.tig.ef.command.TigCommandStack.doExecute (TigCommandStack.java:40)
>> at
>>
org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:164)
>> at
>>
org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:217)
>> at
>>
org.eclipse.emf.edit.ui.action.StaticSelectionCommandAction. run(StaticSelectionCommandAction.java:232)
>>
>>
>>> Eike Stepper wrote:
>>>
>>>> Stéphane Fournier schrieb:
>>>>> Eike Stepper wrote:
>>>>>
>>>>> I tried what you suggested at 2).
>>>>> Now, I got the exception below. I'm using the embbeded derby store.
>>>>>
>>>>> Indeed, after the resource creation a log mentionned that Legacy system
>>>>> is not available. What does it mean ?
>>>> Usually an indication that you are trying to attach non-native objects
>>>> to a transaction (or a bug).
>>>> but from the stack trace I can see that you're not using a brand new CDO
>>>> source from HEAD.
>>>> Only yesterday we committed substantial changes. Can youplease re-test
>>>> with newest HEAD?
>>>
>>>> Cheers
>>>> /Eike
>>>
>>>>>
>>>>> Ok, to give you feedbacks to run editor based on CDO and EMF
>>>>> Transaction, if I succeed ;)
>>>>>
>>>>> Stephane.
>>>>>
>>>>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
>>>>> system not available
>>>>> at
>>>
org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
>>>>>
>>>>> at
>>>
org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
>>>>>
>>>>> at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
>>>>> at
>>>
org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>>>>> at
>>>
org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>>>>>
>>>>> at
>>>
org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>>>>>
>>>>> at
>>>
org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>>>>>
>>>>> at
>>>
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>>>>>
>>>>> at
>>>
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>>>>>
>>>>> at
>>>
com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Stéphane Fournier schrieb:
>>>>>>> Hi Eike,
>>>>>>>
>>>>>>> Yes, I have generated the Extended Library model with changes in the
>>>>>>> genmodel as mentionned in the "Preparing EMF Models for CDO" article.
>>>>>>>
>>>>>>> To create a resource, I'm using transaction.createResource(path)
>>>>>>> method. I have moved to getOrCreateResource() method. Once, the
>>>>>>> resource is created, I add it to a resource set owned by a
>>>>>>> transactional editing domain.
>>>>>> Ah! That's not allowed! Because ResourceSet.resources is like a
>>>>>> containment reference it's like a detach from the CDOTransaction!
>>>>>
>>>>>> The best thing you can do is not using EMF Transaction (sorry
>>>>>> Christian!) on top of CDO.
>>>>>
>>>>>> The second best thing you could try is:
>>>>>> 1) Get the ResourceSet out of the TransactionalEditingDomain
>>>>>> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead of
>>>>>> creating a new resource set
>>>>>
>>>>>
>>>>>>>
>>>>>>> Now, at save time, I got this exception stack :
>>>>>>> java.lang.IllegalStateException: Failing event COMMIT in state
>>>>>>> TRANSIENT for CDOResource@oid1
>>> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>>>>>>
>>>>>>> at
>>>>>
>>>
org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>
>>>
org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>
>>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>
>>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>
>>>
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My editor was already working with a transactional editing domain. I
>>>>>>> try CDO to get a multi-user capability on my existing editor. This
>>>>>>> editor is a GMF one that only works with a transational editing
>>>>>>> domain.
>>>>>>> My idea was to open a CDO transaction when the editor is opening.
>>>>>>> After every save operation, I would like to commit the CDO
>>>>>>> transaction to really flush data to the database.
>>>>>>> Between save operations, my transactional editing domain listens to
>>>>>>> model changes.
>>>>>> Many users already asked for compatibility with GMF so I'm very
>>>>>> interested in your results. Please give feedback! ;-)
>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>
>>>>>
>>>>>>>
>>>>>
>>>>>>>
>>>>>>> Stephane.
>>>>>>>
>>>>>>> Eike Stepper wrote:
>>>>>>>
>>>>>>>> Stéphane Fournier schrieb:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Does anyone try to wire the Extended Library Editor (the one from
>>>>>>>>> EMF examples) with CDO server ?
>>>>>>>>>
>>>>>>>>> I'm not using the CDO session views.
>>>>>>>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>>>>>>>> server, open a session, get a transaction and create a cdo
>>>>>>>>> resource.
>>>>>>>>>
>>>>>>>>> Problems raise when I try to add a new library with a writer.
>>>>>>>>>
>>>>>>>>> All created objects seem to be transient. When debugging
>>>>>>>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>>>>>>>> always answers true. Is it normal ?
>>>>>>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>>>>>>> regenerate the Library model after migrating the genmodel to CDO?
>>>>>>>
>>>>>>>> Usually CDOObjects are TANSIENT as long as they're not attached to a
>>>>>>>> CDOTransaction. This is also true for CDOResource (which is a
>>>>>>>> CDOObject, too). How did you create the CDOResource?
>>>>>>>
>>>>>>>> The best way is transaction.createResource(path). If objects are
>>>>>>>> then attached to other objects that are already attached, the new
>>>>>>>> objects will also transition from TRANSIENT to NEW.
>>>>>>>
>>>>>>>>>
>>>>>>>>> When I commit the transaction, that fails with this message :
>>>>>>>>> [ERROR] SQL Exception: The statement was aborted because it would
>>>>>>>>> have caused a duplicate key value in a unique or primary key
>>>>>>>>> constraint or unique index identified by 'CDORESOURCE_IDX0' defined
>>>>>>>>> on 'CDORESOURCE'.
>>>>>>>> Looks as if a resource with that path (i.e. URI) is already stored
>>>>>>>> in the repository.
>>>>>>>> Either clear your database from previous attempts or use a different
>>>>>>>> resourcepath or call transaction.getOrCreateResource(path).
>>>>>>>
>>>>>>>>> Before I commit the transaction, I have no exception in eclipse log
>>>>>>>>> file.
>>>>>>>>>
>>>>>>>>> N.B : Extended Library editor runs with an editing domain which is
>>>>>>>>> an EMF Transactional one.
>>>>>>>> That's (IMHO) generally not a good idea!
>>>>>>>> Why do you add a second transactional layer on top of CDO?
>>>>>>>
>>>>>>>> Cheers
>>>>>>>> /Eike
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
|
|
|
| Re: [CDO] ExtendedLibrary sample with CDO ? [message #422721 is a reply to message #422720] |
Mon, 15 September 2008 05:27 |
| Eclipse User |
|
|
|
Stéphane Fournier schrieb:
> Thanks folks for your support !
> I missed the following point : to create the marker file (CDO.MF).
Gosh! People always used to criticize me for the lack of documentation
and now you don't read it! :P
> I can test again mixing CDO transactions and EMFT transactions.
>
> Stephane.
>
>
> Simon McDuff wrote:
>
>> Hi Stephane,
>
>> CDO do not support Legacy object anymore.
>> I know Eike is currently working on a feature in EMF that will allow
>> CDO to support easily legacy objects. In my opinion, it is a question
>> of time (months. :-)).
>
>> To be able to persist objects through CDO please follow this guideline:
>>
> http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO#Modify_ an_Existing_GenModel
>
>
>> You just need to modify your genmodel.
>
>> Simon
>
>
>
>> "Stéphane Fournier" <stephane.fournier@netcourrier.com> a écrit dans
>> le message de news: gaha51$145$1@build.eclipse.org...
>>> Comments below.
>>> At home, I can use thunderbird to read newsgroup ouf :)
>>> Stéphane Fournier wrote:
>>>> Ok Eike, I'll check-out the latest release immediately.
>>>> I will test that on next Monday.
>>>>
>>>> Stephane.
>>>>
>>>
>>> Hi Eike,
>>> I checked out the latest release and I tested again. I got the
>>> exception below.
>>>
>>> When you said :
>>> Usually an indication that you are trying to attach non-native
>>> objects to a transaction (or a bug).
>>>
>>> What does it mean exactly "attach non-native objects"? EMF objects
>>> that do not extend CDO objects ?
>>> I'm sorry if the question is stupid, but to make sure I've correctly
>>> understand.
>>>
>>> Stephane.
>>>
>>>
>>> Exception stack :
>>>
>>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
>>> system not available
>>> at
> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl$Persisten tContents.inverseAdd(CDOResourceImpl.java:567)
>
>>> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:448)
>
>>> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>
>>> at
>>> org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>>>
>>> at
>>> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>>> at
> org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>
>>> at
> org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>
>>> at
> org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>
>>> at
> org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>
>>> at
> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>
>>> at
> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>
>>> at
> com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>
>>> at
> com.thalesgroup.mde.tig.ef.command.TigCommandStack.doExecute (TigCommandStack.java:40)
>
>>> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:164)
>
>>> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:217)
>
>>> at
> org.eclipse.emf.edit.ui.action.StaticSelectionCommandAction. run(StaticSelectionCommandAction.java:232)
>
>>>
>>>
>>>> Eike Stepper wrote:
>>>>
>>>>> Stéphane Fournier schrieb:
>>>>>> Eike Stepper wrote:
>>>>>>
>>>>>> I tried what you suggested at 2).
>>>>>> Now, I got the exception below. I'm using the embbeded derby store.
>>>>>>
>>>>>> Indeed, after the resource creation a log mentionned that Legacy
>>>>>> system is not available. What does it mean ?
>>>>> Usually an indication that you are trying to attach non-native
>>>>> objects to a transaction (or a bug).
>>>>> but from the stack trace I can see that you're not using a brand
>>>>> new CDO source from HEAD.
>>>>> Only yesterday we committed substantial changes. Can youplease
>>>>> re-test with newest HEAD?
>>>>
>>>>> Cheers
>>>>> /Eike
>>>>
>>>>>>
>>>>>> Ok, to give you feedbacks to run editor based on CDO and EMF
>>>>>> Transaction, if I succeed ;)
>>>>>>
>>>>>> Stephane.
>>>>>>
>>>>>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException:
>>>>>> Legacy system not available
>>>>>> at
>>>>
> org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
>
>>>>>>
>>>>>> at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
>>>>>> at
>>>>
> org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>
>>>>>>
>>>>>> at
>>>>
> com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Stéphane Fournier schrieb:
>>>>>>>> Hi Eike,
>>>>>>>>
>>>>>>>> Yes, I have generated the Extended Library model with changes
>>>>>>>> in the genmodel as mentionned in the "Preparing EMF Models for
>>>>>>>> CDO" article.
>>>>>>>>
>>>>>>>> To create a resource, I'm using
>>>>>>>> transaction.createResource(path) method. I have moved to
>>>>>>>> getOrCreateResource() method. Once, the resource is created, I
>>>>>>>> add it to a resource set owned by a transactional editing domain.
>>>>>>> Ah! That's not allowed! Because ResourceSet.resources is like a
>>>>>>> containment reference it's like a detach from the CDOTransaction!
>>>>>>
>>>>>>> The best thing you can do is not using EMF Transaction (sorry
>>>>>>> Christian!) on top of CDO.
>>>>>>
>>>>>>> The second best thing you could try is:
>>>>>>> 1) Get the ResourceSet out of the TransactionalEditingDomain
>>>>>>> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1)
>>>>>>> instead of creating a new resource set
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Now, at save time, I got this exception stack :
>>>>>>>> java.lang.IllegalStateException: Failing event COMMIT in state
>>>>>>>> TRANSIENT for CDOResource@oid1
>>>> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>>>
>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>
> org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>
>>>>>>
>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>
> org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>
>>>>>>
>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>
>>>>>>
>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>
>>>>>>
>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>
> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> My editor was already working with a transactional editing
>>>>>>>> domain. I try CDO to get a multi-user capability on my existing
>>>>>>>> editor. This editor is a GMF one that only works with a
>>>>>>>> transational editing domain.
>>>>>>>> My idea was to open a CDO transaction when the editor is
>>>>>>>> opening. After every save operation, I would like to commit the
>>>>>>>> CDO transaction to really flush data to the database.
>>>>>>>> Between save operations, my transactional editing domain
>>>>>>>> listens to model changes.
>>>>>>> Many users already asked for compatibility with GMF so I'm very
>>>>>>> interested in your results. Please give feedback! ;-)
>>>>>>
>>>>>>> Cheers
>>>>>>> /Eike
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Stephane.
>>>>>>>>
>>>>>>>> Eike Stepper wrote:
>>>>>>>>
>>>>>>>>> Stéphane Fournier schrieb:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Does anyone try to wire the Extended Library Editor (the one
>>>>>>>>>> from EMF examples) with CDO server ?
>>>>>>>>>>
>>>>>>>>>> I'm not using the CDO session views.
>>>>>>>>>> I made some changes ExtendedLibrary editor to connect it to a
>>>>>>>>>> CDO server, open a session, get a transaction and create a
>>>>>>>>>> cdo resource.
>>>>>>>>>>
>>>>>>>>>> Problems raise when I try to add a new library with a writer.
>>>>>>>>>>
>>>>>>>>>> All created objects seem to be transient. When debugging
>>>>>>>>>> CDOObjectImpl.dynamicSet() method, and
>>>>>>>>>> FSMUtil.isTransient(this) always answers true. Is it normal ?
>>>>>>>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>>>>>>>> regenerate the Library model after migrating the genmodel to CDO?
>>>>>>>>
>>>>>>>>> Usually CDOObjects are TANSIENT as long as they're not
>>>>>>>>> attached to a CDOTransaction. This is also true for
>>>>>>>>> CDOResource (which is a CDOObject, too). How did you create
>>>>>>>>> the CDOResource?
>>>>>>>>
>>>>>>>>> The best way is transaction.createResource(path). If objects
>>>>>>>>> are then attached to other objects that are already attached,
>>>>>>>>> the new objects will also transition from TRANSIENT to NEW.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When I commit the transaction, that fails with this message :
>>>>>>>>>> [ERROR] SQL Exception: The statement was aborted because it
>>>>>>>>>> would have caused a duplicate key value in a unique or
>>>>>>>>>> primary key constraint or unique index identified by
>>>>>>>>>> 'CDORESOURCE_IDX0' defined on 'CDORESOURCE'.
>>>>>>>>> Looks as if a resource with that path (i.e. URI) is already
>>>>>>>>> stored in the repository.
>>>>>>>>> Either clear your database from previous attempts or use a
>>>>>>>>> different resourcepath or call
>>>>>>>>> transaction.getOrCreateResource(path).
>>>>>>>>
>>>>>>>>>> Before I commit the transaction, I have no exception in
>>>>>>>>>> eclipse log file.
>>>>>>>>>>
>>>>>>>>>> N.B : Extended Library editor runs with an editing domain
>>>>>>>>>> which is an EMF Transactional one.
>>>>>>>>> That's (IMHO) generally not a good idea!
>>>>>>>>> Why do you add a second transactional layer on top of CDO?
>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> /Eike
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>
>
|
|
|
Goto Forum:
Current Time: Wed Jul 23 12:25:13 EDT 2025
Powered by FUDForum. Page generated in 0.32071 seconds |
Home