Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » CDO and GMF
| CDO and GMF [message #43319] |
Thu, 03 August 2006 05:22  |
Eclipse User |
|
|
|
Does anyone use cdo and GMF,
the generated GMF editor uses FileDiagramEditor, maby it must be
possible to extend from CdoDiagramEditor.
Does anyone have an idea how CdoDiagramEditor has to look like.
Chris
|
|
| | |
| Re: CDO and GMF [message #43522 is a reply to message #43461] |
Fri, 04 August 2006 04:14  |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Chris,
CDO operates directly on model level (as opposed to edit framework
level). As you already played with your own CDO client code you know
that you don't even need an edit layer on top of CDO. Nevertheless the
CDO editor uses (like all EMF generated editors) an unmodified edit
layer above CDO.
What I believe to know about EMFT Transaction (and that seems to be used
by the GMF generated editors) is that transactionality is achieved
through a special edit framework layer. These transactional facilities
are quite different in several aspects. or example EMFT Transactions
rely on client cooperation (it only works if *all* clients respect and
use a special API). CDO in contrast does not. Since it is integrated
directly into the model code, it doesn't require a CDOResource client to
know about CDO and its transactional semantics.
If you try to use a CDOResource within a GMF editor, you have two
transactional systems on top of each other. I'm not very sure what
*should* happen if, for example, a CDO transaction is rolled back while
being in the middle of a GMF transaction or vice versa.
Maybe these issues can be solved but as I said, I'm rather unexperienced
with both EMFT Transaction and GMF. If someone wants to explore this
area and can contribute patches for CDO I will review and test them.
Cheers
/Eike
Chris Lenz schrieb:
> Don't understand this, GMF has an own file _diagram. That references an
> EMF-XMI file. This Reference should be CDO-resource.
>
> has nobody done that yet??
>
> Eike Stepper schrieb:
>
>> Chris,
>>
>> I have no experience with GMF so far (it's on the plan for a long time
>> now).
>> Someone else told me that it's not possible to use GMF with CDO.
>> The reason is that GMF uses its own transactional model (EMFT
>> Transaction) and that's not compatible with the CDO transactions.
>>
>> Eventually I can consider this issue for one of the next releases, but
>> I'm not completely sure about the semantics of multiple/layered
>> transaction models.
>>
>> Cheers
>> /Eike
>>
>>
>>
>> Chris Lenz schrieb:
>>
>>> Does anyone use cdo and GMF,
>>>
>>> the generated GMF editor uses FileDiagramEditor, maby it must be
>>> possible to extend from CdoDiagramEditor.
>>>
>>> Does anyone have an idea how CdoDiagramEditor has to look like.
>>>
>>> Chris
>>>
>>>
|
|
|
| Re: CDO and GMF [message #43722 is a reply to message #43522] |
Mon, 07 August 2006 11:39 |
| Eclipse User |
|
|
|
Clear I understand this, but I want to try this.
But I have always the same problem:
the diagram has a reference to an other file. You know this thats the
thing with eResolve where the proxy resources are reloaded.
But if I rewrite the reference to:
<element xmi:type="organisation:Organisation"
href="cdo:///org/eclipse/net4j/cdo/test/test#/"/>
This could not be resolfed. I don't get any error, but it is not
resolved. Did you have any suggestions.
Chris
Eike Stepper schrieb:
> Chris,
>
> CDO operates directly on model level (as opposed to edit framework
> level). As you already played with your own CDO client code you know
> that you don't even need an edit layer on top of CDO. Nevertheless the
> CDO editor uses (like all EMF generated editors) an unmodified edit
> layer above CDO.
>
> What I believe to know about EMFT Transaction (and that seems to be used
> by the GMF generated editors) is that transactionality is achieved
> through a special edit framework layer. These transactional facilities
> are quite different in several aspects. or example EMFT Transactions
> rely on client cooperation (it only works if *all* clients respect and
> use a special API). CDO in contrast does not. Since it is integrated
> directly into the model code, it doesn't require a CDOResource client to
> know about CDO and its transactional semantics.
>
> If you try to use a CDOResource within a GMF editor, you have two
> transactional systems on top of each other. I'm not very sure what
> *should* happen if, for example, a CDO transaction is rolled back while
> being in the middle of a GMF transaction or vice versa.
>
> Maybe these issues can be solved but as I said, I'm rather unexperienced
> with both EMFT Transaction and GMF. If someone wants to explore this
> area and can contribute patches for CDO I will review and test them.
>
> Cheers
> /Eike
>
>
>
> Chris Lenz schrieb:
>> Don't understand this, GMF has an own file _diagram. That references an
>> EMF-XMI file. This Reference should be CDO-resource.
>>
>> has nobody done that yet??
>>
>> Eike Stepper schrieb:
>>
>>> Chris,
>>>
>>> I have no experience with GMF so far (it's on the plan for a long time
>>> now).
>>> Someone else told me that it's not possible to use GMF with CDO.
>>> The reason is that GMF uses its own transactional model (EMFT
>>> Transaction) and that's not compatible with the CDO transactions.
>>>
>>> Eventually I can consider this issue for one of the next releases, but
>>> I'm not completely sure about the semantics of multiple/layered
>>> transaction models.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>>> Chris Lenz schrieb:
>>>
>>>> Does anyone use cdo and GMF,
>>>>
>>>> the generated GMF editor uses FileDiagramEditor, maby it must be
>>>> possible to extend from CdoDiagramEditor.
>>>>
>>>> Does anyone have an idea how CdoDiagramEditor has to look like.
>>>>
>>>> Chris
>>>>
|
|
|
| Re: CDO and GMF [message #43743 is a reply to message #43722] |
Tue, 08 August 2006 01:30 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Chris Lenz schrieb:
> Clear I understand this, but I want to try this.
>
> But I have always the same problem:
> the diagram has a reference to an other file. You know this thats the
> thing with eResolve where the proxy resources are reloaded.
> But if I rewrite the reference to:
> <element xmi:type="organisation:Organisation"
> href="cdo:///org/eclipse/net4j/cdo/test/test#/"/>
>
The URI is not valid for CDO.
CDO is expecting a flat (long) integer ID called OID. The OID is bitwise
encoded by the OIDEncoder.
It consists of a RID (Resource Identifier) and an OID Fragment part. By
default the fragment part forms the lower 48 bits of the OID.
This can be configured in the
/org.eclipse.emf.cdo.examples.client/META-INF/common.xml
and must match the
/org.eclipse.emf.cdo.examples.server/META-INF/server.xml
You can see the code to create a proxy URI in ResourceManagerImpl:
public URI createProxyURI(long oid)
{
OIDEncoder oidEncoder = packageManager.getOidEncoder();
int rid = oidEncoder.getRID(oid);
long oidFragment = oidEncoder.getOIDFragment(oid);
StringBuffer buffer = new StringBuffer();
buffer.append(CDOProtocol.PROTOCOL_SCHEME);
buffer.append(rid);
buffer.append("#");
buffer.append(oidFragment);
if (isDebugEnabled())
{
debug("Creating proxy URI " + buffer.toString());
}
return URI.createURI(buffer.toString());
}
When CDO receives an object with a reference the following occurs:
[DEBUG] common.connector-channel-2: Receiving reference "authors":
1:2, cid=3, feature=1
[DEBUG] common.connector-channel-2: Searching proxy 1:2
[DEBUG] common.connector-channel-2: Creating proxy Author 1:2
[DEBUG] common.client.resourceManager-2: Creating proxy URI *cdo://1#2*
The last line shows the format of a valid CDO proxy URI.
The CDOResourceFactoryImpl is able to create and load resources by path.
The server maintains a bidirectional rid <-> path map.
But there is no way to query an object through a hierarchical fragment.
The effort to maintain intra-resource moves would be indeterministic.
I have no idea where the href URI comes from, but CDO can't understand
it. At least the fragment part can't be hierachical.
Cheers
/Eike
> This could not be resolfed. I don't get any error, but it is not
> resolved. Did you have any suggestions.
>
> Chris
> Eike Stepper schrieb:
>
>> Chris,
>>
>> CDO operates directly on model level (as opposed to edit framework
>> level). As you already played with your own CDO client code you know
>> that you don't even need an edit layer on top of CDO. Nevertheless the
>> CDO editor uses (like all EMF generated editors) an unmodified edit
>> layer above CDO.
>>
>> What I believe to know about EMFT Transaction (and that seems to be used
>> by the GMF generated editors) is that transactionality is achieved
>> through a special edit framework layer. These transactional facilities
>> are quite different in several aspects. or example EMFT Transactions
>> rely on client cooperation (it only works if *all* clients respect and
>> use a special API). CDO in contrast does not. Since it is integrated
>> directly into the model code, it doesn't require a CDOResource client to
>> know about CDO and its transactional semantics.
>>
>> If you try to use a CDOResource within a GMF editor, you have two
>> transactional systems on top of each other. I'm not very sure what
>> *should* happen if, for example, a CDO transaction is rolled back while
>> being in the middle of a GMF transaction or vice versa.
>>
>> Maybe these issues can be solved but as I said, I'm rather unexperienced
>> with both EMFT Transaction and GMF. If someone wants to explore this
>> area and can contribute patches for CDO I will review and test them.
>>
>> Cheers
>> /Eike
>>
>>
>>
>> Chris Lenz schrieb:
>>
>>> Don't understand this, GMF has an own file _diagram. That references an
>>> EMF-XMI file. This Reference should be CDO-resource.
>>>
>>> has nobody done that yet??
>>>
>>> Eike Stepper schrieb:
>>>
>>>
>>>> Chris,
>>>>
>>>> I have no experience with GMF so far (it's on the plan for a long time
>>>> now).
>>>> Someone else told me that it's not possible to use GMF with CDO.
>>>> The reason is that GMF uses its own transactional model (EMFT
>>>> Transaction) and that's not compatible with the CDO transactions.
>>>>
>>>> Eventually I can consider this issue for one of the next releases, but
>>>> I'm not completely sure about the semantics of multiple/layered
>>>> transaction models.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>>
>>>> Chris Lenz schrieb:
>>>>
>>>>
>>>>> Does anyone use cdo and GMF,
>>>>>
>>>>> the generated GMF editor uses FileDiagramEditor, maby it must be
>>>>> possible to extend from CdoDiagramEditor.
>>>>>
>>>>> Does anyone have an idea how CdoDiagramEditor has to look like.
>>>>>
>>>>> Chris
>>>>>
>>>>>
|
|
|
| Re: CDO and GMF [message #584415 is a reply to message #43319] |
Thu, 03 August 2006 08:57 |
| Eclipse User |
|
|
|
Chris,
I have no experience with GMF so far (it's on the plan for a long time now).
Someone else told me that it's not possible to use GMF with CDO.
The reason is that GMF uses its own transactional model (EMFT
Transaction) and that's not compatible with the CDO transactions.
Eventually I can consider this issue for one of the next releases, but
I'm not completely sure about the semantics of multiple/layered
transaction models.
Cheers
/Eike
Chris Lenz schrieb:
> Does anyone use cdo and GMF,
>
> the generated GMF editor uses FileDiagramEditor, maby it must be
> possible to extend from CdoDiagramEditor.
>
> Does anyone have an idea how CdoDiagramEditor has to look like.
>
> Chris
>
|
|
|
| Re: CDO and GMF [message #584440 is a reply to message #43398] |
Thu, 03 August 2006 12:40 |
| Eclipse User |
|
|
|
Don't understand this, GMF has an own file _diagram. That references an
EMF-XMI file. This Reference should be CDO-resource.
has nobody done that yet??
Eike Stepper schrieb:
> Chris,
>
> I have no experience with GMF so far (it's on the plan for a long time
> now).
> Someone else told me that it's not possible to use GMF with CDO.
> The reason is that GMF uses its own transactional model (EMFT
> Transaction) and that's not compatible with the CDO transactions.
>
> Eventually I can consider this issue for one of the next releases, but
> I'm not completely sure about the semantics of multiple/layered
> transaction models.
>
> Cheers
> /Eike
>
>
>
> Chris Lenz schrieb:
>> Does anyone use cdo and GMF,
>>
>> the generated GMF editor uses FileDiagramEditor, maby it must be
>> possible to extend from CdoDiagramEditor.
>>
>> Does anyone have an idea how CdoDiagramEditor has to look like.
>>
>> Chris
>>
|
|
|
| Re: CDO and GMF [message #584478 is a reply to message #43461] |
Fri, 04 August 2006 04:14 |
| Eclipse User |
|
|
|
Chris,
CDO operates directly on model level (as opposed to edit framework
level). As you already played with your own CDO client code you know
that you don't even need an edit layer on top of CDO. Nevertheless the
CDO editor uses (like all EMF generated editors) an unmodified edit
layer above CDO.
What I believe to know about EMFT Transaction (and that seems to be used
by the GMF generated editors) is that transactionality is achieved
through a special edit framework layer. These transactional facilities
are quite different in several aspects. or example EMFT Transactions
rely on client cooperation (it only works if *all* clients respect and
use a special API). CDO in contrast does not. Since it is integrated
directly into the model code, it doesn't require a CDOResource client to
know about CDO and its transactional semantics.
If you try to use a CDOResource within a GMF editor, you have two
transactional systems on top of each other. I'm not very sure what
*should* happen if, for example, a CDO transaction is rolled back while
being in the middle of a GMF transaction or vice versa.
Maybe these issues can be solved but as I said, I'm rather unexperienced
with both EMFT Transaction and GMF. If someone wants to explore this
area and can contribute patches for CDO I will review and test them.
Cheers
/Eike
Chris Lenz schrieb:
> Don't understand this, GMF has an own file _diagram. That references an
> EMF-XMI file. This Reference should be CDO-resource.
>
> has nobody done that yet??
>
> Eike Stepper schrieb:
>
>> Chris,
>>
>> I have no experience with GMF so far (it's on the plan for a long time
>> now).
>> Someone else told me that it's not possible to use GMF with CDO.
>> The reason is that GMF uses its own transactional model (EMFT
>> Transaction) and that's not compatible with the CDO transactions.
>>
>> Eventually I can consider this issue for one of the next releases, but
>> I'm not completely sure about the semantics of multiple/layered
>> transaction models.
>>
>> Cheers
>> /Eike
>>
>>
>>
>> Chris Lenz schrieb:
>>
>>> Does anyone use cdo and GMF,
>>>
>>> the generated GMF editor uses FileDiagramEditor, maby it must be
>>> possible to extend from CdoDiagramEditor.
>>>
>>> Does anyone have an idea how CdoDiagramEditor has to look like.
>>>
>>> Chris
>>>
>>>
|
|
|
| Re: CDO and GMF [message #584607 is a reply to message #43522] |
Mon, 07 August 2006 11:39 |
| Eclipse User |
|
|
|
Clear I understand this, but I want to try this.
But I have always the same problem:
the diagram has a reference to an other file. You know this thats the
thing with eResolve where the proxy resources are reloaded.
But if I rewrite the reference to:
<element xmi:type="organisation:Organisation"
href="cdo:///org/eclipse/net4j/cdo/test/test#/"/>
This could not be resolfed. I don't get any error, but it is not
resolved. Did you have any suggestions.
Chris
Eike Stepper schrieb:
> Chris,
>
> CDO operates directly on model level (as opposed to edit framework
> level). As you already played with your own CDO client code you know
> that you don't even need an edit layer on top of CDO. Nevertheless the
> CDO editor uses (like all EMF generated editors) an unmodified edit
> layer above CDO.
>
> What I believe to know about EMFT Transaction (and that seems to be used
> by the GMF generated editors) is that transactionality is achieved
> through a special edit framework layer. These transactional facilities
> are quite different in several aspects. or example EMFT Transactions
> rely on client cooperation (it only works if *all* clients respect and
> use a special API). CDO in contrast does not. Since it is integrated
> directly into the model code, it doesn't require a CDOResource client to
> know about CDO and its transactional semantics.
>
> If you try to use a CDOResource within a GMF editor, you have two
> transactional systems on top of each other. I'm not very sure what
> *should* happen if, for example, a CDO transaction is rolled back while
> being in the middle of a GMF transaction or vice versa.
>
> Maybe these issues can be solved but as I said, I'm rather unexperienced
> with both EMFT Transaction and GMF. If someone wants to explore this
> area and can contribute patches for CDO I will review and test them.
>
> Cheers
> /Eike
>
>
>
> Chris Lenz schrieb:
>> Don't understand this, GMF has an own file _diagram. That references an
>> EMF-XMI file. This Reference should be CDO-resource.
>>
>> has nobody done that yet??
>>
>> Eike Stepper schrieb:
>>
>>> Chris,
>>>
>>> I have no experience with GMF so far (it's on the plan for a long time
>>> now).
>>> Someone else told me that it's not possible to use GMF with CDO.
>>> The reason is that GMF uses its own transactional model (EMFT
>>> Transaction) and that's not compatible with the CDO transactions.
>>>
>>> Eventually I can consider this issue for one of the next releases, but
>>> I'm not completely sure about the semantics of multiple/layered
>>> transaction models.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>>> Chris Lenz schrieb:
>>>
>>>> Does anyone use cdo and GMF,
>>>>
>>>> the generated GMF editor uses FileDiagramEditor, maby it must be
>>>> possible to extend from CdoDiagramEditor.
>>>>
>>>> Does anyone have an idea how CdoDiagramEditor has to look like.
>>>>
>>>> Chris
>>>>
|
|
|
| Re: CDO and GMF [message #584624 is a reply to message #43722] |
Tue, 08 August 2006 01:30 |
| Eclipse User |
|
|
|
Chris Lenz schrieb:
> Clear I understand this, but I want to try this.
>
> But I have always the same problem:
> the diagram has a reference to an other file. You know this thats the
> thing with eResolve where the proxy resources are reloaded.
> But if I rewrite the reference to:
> <element xmi:type="organisation:Organisation"
> href="cdo:///org/eclipse/net4j/cdo/test/test#/"/>
>
The URI is not valid for CDO.
CDO is expecting a flat (long) integer ID called OID. The OID is bitwise
encoded by the OIDEncoder.
It consists of a RID (Resource Identifier) and an OID Fragment part. By
default the fragment part forms the lower 48 bits of the OID.
This can be configured in the
/org.eclipse.emf.cdo.examples.client/META-INF/common.xml
and must match the
/org.eclipse.emf.cdo.examples.server/META-INF/server.xml
You can see the code to create a proxy URI in ResourceManagerImpl:
public URI createProxyURI(long oid)
{
OIDEncoder oidEncoder = packageManager.getOidEncoder();
int rid = oidEncoder.getRID(oid);
long oidFragment = oidEncoder.getOIDFragment(oid);
StringBuffer buffer = new StringBuffer();
buffer.append(CDOProtocol.PROTOCOL_SCHEME);
buffer.append(rid);
buffer.append("#");
buffer.append(oidFragment);
if (isDebugEnabled())
{
debug("Creating proxy URI " + buffer.toString());
}
return URI.createURI(buffer.toString());
}
When CDO receives an object with a reference the following occurs:
[DEBUG] common.connector-channel-2: Receiving reference "authors":
1:2, cid=3, feature=1
[DEBUG] common.connector-channel-2: Searching proxy 1:2
[DEBUG] common.connector-channel-2: Creating proxy Author 1:2
[DEBUG] common.client.resourceManager-2: Creating proxy URI *cdo://1#2*
The last line shows the format of a valid CDO proxy URI.
The CDOResourceFactoryImpl is able to create and load resources by path.
The server maintains a bidirectional rid <-> path map.
But there is no way to query an object through a hierarchical fragment.
The effort to maintain intra-resource moves would be indeterministic.
I have no idea where the href URI comes from, but CDO can't understand
it. At least the fragment part can't be hierachical.
Cheers
/Eike
> This could not be resolfed. I don't get any error, but it is not
> resolved. Did you have any suggestions.
>
> Chris
> Eike Stepper schrieb:
>
>> Chris,
>>
>> CDO operates directly on model level (as opposed to edit framework
>> level). As you already played with your own CDO client code you know
>> that you don't even need an edit layer on top of CDO. Nevertheless the
>> CDO editor uses (like all EMF generated editors) an unmodified edit
>> layer above CDO.
>>
>> What I believe to know about EMFT Transaction (and that seems to be used
>> by the GMF generated editors) is that transactionality is achieved
>> through a special edit framework layer. These transactional facilities
>> are quite different in several aspects. or example EMFT Transactions
>> rely on client cooperation (it only works if *all* clients respect and
>> use a special API). CDO in contrast does not. Since it is integrated
>> directly into the model code, it doesn't require a CDOResource client to
>> know about CDO and its transactional semantics.
>>
>> If you try to use a CDOResource within a GMF editor, you have two
>> transactional systems on top of each other. I'm not very sure what
>> *should* happen if, for example, a CDO transaction is rolled back while
>> being in the middle of a GMF transaction or vice versa.
>>
>> Maybe these issues can be solved but as I said, I'm rather unexperienced
>> with both EMFT Transaction and GMF. If someone wants to explore this
>> area and can contribute patches for CDO I will review and test them.
>>
>> Cheers
>> /Eike
>>
>>
>>
>> Chris Lenz schrieb:
>>
>>> Don't understand this, GMF has an own file _diagram. That references an
>>> EMF-XMI file. This Reference should be CDO-resource.
>>>
>>> has nobody done that yet??
>>>
>>> Eike Stepper schrieb:
>>>
>>>
>>>> Chris,
>>>>
>>>> I have no experience with GMF so far (it's on the plan for a long time
>>>> now).
>>>> Someone else told me that it's not possible to use GMF with CDO.
>>>> The reason is that GMF uses its own transactional model (EMFT
>>>> Transaction) and that's not compatible with the CDO transactions.
>>>>
>>>> Eventually I can consider this issue for one of the next releases, but
>>>> I'm not completely sure about the semantics of multiple/layered
>>>> transaction models.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>>
>>>> Chris Lenz schrieb:
>>>>
>>>>
>>>>> Does anyone use cdo and GMF,
>>>>>
>>>>> the generated GMF editor uses FileDiagramEditor, maby it must be
>>>>> possible to extend from CdoDiagramEditor.
>>>>>
>>>>> Does anyone have an idea how CdoDiagramEditor has to look like.
>>>>>
>>>>> Chris
>>>>>
>>>>>
|
|
|
Goto Forum:
Current Time: Wed Jul 09 08:07:02 EDT 2025
Powered by FUDForum. Page generated in 0.05567 seconds |
Home