Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc)

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » CDO Resources

Fri, 18 August 2006 04:17

Eclipse User

Hi eike,

now I'am playing really a while with cdo and it is still cool.

But I have one problem:

I build a CDOHelper:
It can load a Resource from xmi file and save it to CDO.
But the otherway around is a bit tricky:
It always creates only something like the following:

<?xml version="1.0" encoding="ASCII"?>
<organisation:Organisation xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
name="test">
<roles href="cdo://2#2"/>
<roles href="cdo://2#3"/>
<roles href="cdo://2#4"/>
<roles href="cdo://2#5"/>
<roles href="cdo://2#6"/>
<users href="cdo://2#7"/>
<users href="cdo://2#8"/>
<users href="cdo://2#9"/>
<processes href="cdo://2#10"/>
<processes href="cdo://2#11"/>
<processes href="cdo://2#12"/>
</organisation:Organisation>

Thats the code?

public void saveToFile(Organisation org, String string) {
try {
ResourceSet resourceSet = new ResourceSetImpl();
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
.put("organisation", new XMIResourceFactoryImpl());
resourceSet.getPackageRegistry().put("organisation",
OrganisationPackage.eINSTANCE);
URI fileURI = URI.createFileURI(new File(string)
.getAbsolutePath());
Resource poResource = resourceSet.createResource(fileURI);
poResource.getContents().add(org);

poResource.save(new HashMap());
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

}

Re: CDO Resources [message #45346 is a reply to message #45286]

Fri, 18 August 2006 09:49

Eclipse User

Originally posted by: stepper.sympedia.de

Chris,

What is the exact URI you want to save to (does it end in ".organisation")?

Is this executed against the latest CVS sources?
There is a recent change in how eResource() works for CDOPersistable
objects.
With your info below I recognize that there might be issues with
re-attached objects.
Currently an object always returns the CDOResource it was initially
attached to.
Please open a Bugzilla for this.

The latest CVS sources contain a number of bug fixes (we have
integration tests now).
Please try if the problem persists with that version.

Did you try to copy the objects from a CDOResource to the XMIResource?
There are newsgroup threads discussing that.

If all does not help, could you send me a zip with the projects so that
I can play around with them?

Cheers
/Eike

Chris Lenz schrieb:
> Hi eike,
>
> now I'am playing really a while with cdo and it is still cool.
>
> But I have one problem:
>
> I build a CDOHelper:
> It can load a Resource from xmi file and save it to CDO.
> But the otherway around is a bit tricky:
> It always creates only something like the following:
>
> <?xml version="1.0" encoding="ASCII"?>
> <organisation:Organisation xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
> name="test">
> <roles href="cdo://2#2"/>
> <roles href="cdo://2#3"/>
> <roles href="cdo://2#4"/>
> <roles href="cdo://2#5"/>
> <roles href="cdo://2#6"/>
> <users href="cdo://2#7"/>
> <users href="cdo://2#8"/>
> <users href="cdo://2#9"/>
> <processes href="cdo://2#10"/>
> <processes href="cdo://2#11"/>
> <processes href="cdo://2#12"/>
> </organisation:Organisation>
>
>
> Thats the code?
>
> public void saveToFile(Organisation org, String string) {
> try {
> ResourceSet resourceSet = new ResourceSetImpl();
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
> .put("organisation", new XMIResourceFactoryImpl());
> resourceSet.getPackageRegistry().put("organisation",
> OrganisationPackage.eINSTANCE);
> URI fileURI = URI.createFileURI(new File(string)
> .getAbsolutePath());
> Resource poResource = resourceSet.createResource(fileURI);
> poResource.getContents().add(org);
>
> poResource.save(new HashMap());
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
>

Re: CDO Resources [message #45455 is a reply to message #45286]

Fri, 18 August 2006 15:02

Eclipse User

Originally posted by: stepper.sympedia.de

Chris,

If you think that import and export buttons in the CDO Explorer are a
good idea, please feel free to open an enhancement request.

Cheers
/Eike

Chris Lenz schrieb:
> Hi eike,
>
> now I'am playing really a while with cdo and it is still cool.
>
> But I have one problem:
>
> I build a CDOHelper:
> It can load a Resource from xmi file and save it to CDO.
> But the otherway around is a bit tricky:
> It always creates only something like the following:
>
> <?xml version="1.0" encoding="ASCII"?>
> <organisation:Organisation xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
> name="test">
> <roles href="cdo://2#2"/>
> <roles href="cdo://2#3"/>
> <roles href="cdo://2#4"/>
> <roles href="cdo://2#5"/>
> <roles href="cdo://2#6"/>
> <users href="cdo://2#7"/>
> <users href="cdo://2#8"/>
> <users href="cdo://2#9"/>
> <processes href="cdo://2#10"/>
> <processes href="cdo://2#11"/>
> <processes href="cdo://2#12"/>
> </organisation:Organisation>
>
>
> Thats the code?
>
> public void saveToFile(Organisation org, String string) {
> try {
> ResourceSet resourceSet = new ResourceSetImpl();
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
> .put("organisation", new XMIResourceFactoryImpl());
> resourceSet.getPackageRegistry().put("organisation",
> OrganisationPackage.eINSTANCE);
> URI fileURI = URI.createFileURI(new File(string)
> .getAbsolutePath());
> Resource poResource = resourceSet.createResource(fileURI);
> poResource.getContents().add(org);
>
> poResource.save(new HashMap());
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
>

Re: CDO Resources [message #45483 is a reply to message #45286]

Fri, 18 August 2006 15:11

Eclipse User

Originally posted by: stepper.sympedia.de

Chris,

I think I know what happened to your exported objects. CDO generally
loads objects on demand (even contained ones). Only the root objects are
loaded together with the resource. That's why your root object is
properly serialized to XMI. The contained objects (roles, users,
processes) had not been loaded when you attached the root object to a
different resource. The proxy URIs still apply to the CDO resource but
that is no longer the container of the root. So they're not loaded
anymore and don't get resolved.

I really suggest that you EcoreUtil.copy() the CDO resource and attach
the copy to the XMI resource.

Cheers
/Eike

Chris Lenz schrieb:
> Hi eike,
>
> now I'am playing really a while with cdo and it is still cool.
>
> But I have one problem:
>
> I build a CDOHelper:
> It can load a Resource from xmi file and save it to CDO.
> But the otherway around is a bit tricky:
> It always creates only something like the following:
>
> <?xml version="1.0" encoding="ASCII"?>
> <organisation:Organisation xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
> name="test">
> <roles href="cdo://2#2"/>
> <roles href="cdo://2#3"/>
> <roles href="cdo://2#4"/>
> <roles href="cdo://2#5"/>
> <roles href="cdo://2#6"/>
> <users href="cdo://2#7"/>
> <users href="cdo://2#8"/>
> <users href="cdo://2#9"/>
> <processes href="cdo://2#10"/>
> <processes href="cdo://2#11"/>
> <processes href="cdo://2#12"/>
> </organisation:Organisation>
>
>
> Thats the code?
>
> public void saveToFile(Organisation org, String string) {
> try {
> ResourceSet resourceSet = new ResourceSetImpl();
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
> .put("organisation", new XMIResourceFactoryImpl());
> resourceSet.getPackageRegistry().put("organisation",
> OrganisationPackage.eINSTANCE);
> URI fileURI = URI.createFileURI(new File(string)
> .getAbsolutePath());
> Resource poResource = resourceSet.createResource(fileURI);
> poResource.getContents().add(org);
>
> poResource.save(new HashMap());
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
>

Re: CDO Resources [message #45542 is a reply to message #45483]

Mon, 21 August 2006 06:05

Eclipse User

I tried this:
Organisation org =
help.loadFromRepository("cdo:///squam/test/sampleorg");
Organisation obj = (Organisation)EcoreUtil.copy(org);
help.saveToFile(obj,"c:\\test.organisation");

That does not work??
Chris
Eike Stepper schrieb:
> Chris,
>
> I think I know what happened to your exported objects. CDO generally
> loads objects on demand (even contained ones). Only the root objects are
> loaded together with the resource. That's why your root object is
> properly serialized to XMI. The contained objects (roles, users,
> processes) had not been loaded when you attached the root object to a
> different resource. The proxy URIs still apply to the CDO resource but
> that is no longer the container of the root. So they're not loaded
> anymore and don't get resolved.
>
> I really suggest that you EcoreUtil.copy() the CDO resource and attach
> the copy to the XMI resource.
>
> Cheers
> /Eike
>
>
> Chris Lenz schrieb:
>> Hi eike,
>>
>> now I'am playing really a while with cdo and it is still cool.
>>
>> But I have one problem:
>>
>> I build a CDOHelper:
>> It can load a Resource from xmi file and save it to CDO.
>> But the otherway around is a bit tricky:
>> It always creates only something like the following:
>>
>> <?xml version="1.0" encoding="ASCII"?>
>> <organisation:Organisation xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>> name="test">
>> <roles href="cdo://2#2"/>
>> <roles href="cdo://2#3"/>
>> <roles href="cdo://2#4"/>
>> <roles href="cdo://2#5"/>
>> <roles href="cdo://2#6"/>
>> <users href="cdo://2#7"/>
>> <users href="cdo://2#8"/>
>> <users href="cdo://2#9"/>
>> <processes href="cdo://2#10"/>
>> <processes href="cdo://2#11"/>
>> <processes href="cdo://2#12"/>
>> </organisation:Organisation>
>>
>>
>> Thats the code?
>>
>> public void saveToFile(Organisation org, String string) {
>> try {
>> ResourceSet resourceSet = new ResourceSetImpl();
>>
>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>> .put("organisation", new XMIResourceFactoryImpl());
>> resourceSet.getPackageRegistry().put("organisation",
>> OrganisationPackage.eINSTANCE);
>> URI fileURI = URI.createFileURI(new File(string)
>> .getAbsolutePath());
>> Resource poResource = resourceSet.createResource(fileURI);
>> poResource.getContents().add(org);
>>
>> poResource.save(new HashMap());
>> } catch (Exception e) {
>> // TODO Auto-generated catch block
>> e.printStackTrace();
>> }
>>
>> }
>>

Re: CDO Resources [message #45573 is a reply to message #45542]

Mon, 21 August 2006 08:44

Eclipse User

Originally posted by: stepper.sympedia.de

Chris,

I've opened Bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
The main outcome is that you have to use something like

protected void preLoadResource(CDOResource cdoResource)
{
for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
it.hasNext();)
{
CDOPersistable persistable = (CDOPersistable) it.next();
persistable.cdoLoad();
}
}

before you try to copy the resource with EcoreUtil.

I have to admit that I'm not completely sure about the influence of
resolveProxies during the copy process.
It seems that it does not automatically lead to loading CDOPersistables
that are proxies.
Ed: Could you explain a bit?

Maybe CDO could override an EObject method so that resolving a proxy
would also load it.
At the moment cdoLoad is only called on explicit access to persistent
features.

Cheers
/Eike

Chris Lenz schrieb:
> I tried this:
> Organisation org =
> help.loadFromRepository("cdo:///squam/test/sampleorg");
> Organisation obj = (Organisation)EcoreUtil.copy(org);
> help.saveToFile(obj,"c:\\test.organisation");
>
> That does not work??
> Chris
> Eike Stepper schrieb:
>
>> Chris,
>>
>> I think I know what happened to your exported objects. CDO generally
>> loads objects on demand (even contained ones). Only the root objects are
>> loaded together with the resource. That's why your root object is
>> properly serialized to XMI. The contained objects (roles, users,
>> processes) had not been loaded when you attached the root object to a
>> different resource. The proxy URIs still apply to the CDO resource but
>> that is no longer the container of the root. So they're not loaded
>> anymore and don't get resolved.
>>
>> I really suggest that you EcoreUtil.copy() the CDO resource and attach
>> the copy to the XMI resource.
>>
>> Cheers
>> /Eike
>>
>>
>> Chris Lenz schrieb:
>>
>>> Hi eike,
>>>
>>> now I'am playing really a while with cdo and it is still cool.
>>>
>>> But I have one problem:
>>>
>>> I build a CDOHelper:
>>> It can load a Resource from xmi file and save it to CDO.
>>> But the otherway around is a bit tricky:
>>> It always creates only something like the following:
>>>
>>> <?xml version="1.0" encoding="ASCII"?>
>>> <organisation:Organisation xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>> name="test">
>>> <roles href="cdo://2#2"/>
>>> <roles href="cdo://2#3"/>
>>> <roles href="cdo://2#4"/>
>>> <roles href="cdo://2#5"/>
>>> <roles href="cdo://2#6"/>
>>> <users href="cdo://2#7"/>
>>> <users href="cdo://2#8"/>
>>> <users href="cdo://2#9"/>
>>> <processes href="cdo://2#10"/>
>>> <processes href="cdo://2#11"/>
>>> <processes href="cdo://2#12"/>
>>> </organisation:Organisation>
>>>
>>>
>>> Thats the code?
>>>
>>> public void saveToFile(Organisation org, String string) {
>>> try {
>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>
>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>> .put("organisation", new XMIResourceFactoryImpl());
>>> resourceSet.getPackageRegistry().put("organisation",
>>> OrganisationPackage.eINSTANCE);
>>> URI fileURI = URI.createFileURI(new File(string)
>>> .getAbsolutePath());
>>> Resource poResource = resourceSet.createResource(fileURI);
>>> poResource.getContents().add(org);
>>>
>>> poResource.save(new HashMap());
>>> } catch (Exception e) {
>>> // TODO Auto-generated catch block
>>> e.printStackTrace();
>>> }
>>>
>>> }
>>>
>>>

Re: CDO Resources [message #45604 is a reply to message #45573]

Mon, 21 August 2006 08:45

Eclipse User

Originally posted by: stepper.sympedia.de

Ed,

I forgot to add you to the cc in the previous posting.
There's a question for you ;-)

Cheers
/Eike

Eike Stepper schrieb:
> Chris,
>
> I've opened Bugzilla
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
> The main outcome is that you have to use something like
>
> protected void preLoadResource(CDOResource cdoResource)
> {
> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
> it.hasNext();)
> {
> CDOPersistable persistable = (CDOPersistable) it.next();
> persistable.cdoLoad();
> }
> }
>
> before you try to copy the resource with EcoreUtil.
>
> I have to admit that I'm not completely sure about the influence of
> resolveProxies during the copy process.
> It seems that it does not automatically lead to loading
> CDOPersistables that are proxies.
> Ed: Could you explain a bit?
>
> Maybe CDO could override an EObject method so that resolving a proxy
> would also load it.
> At the moment cdoLoad is only called on explicit access to persistent
> features.
>
> Cheers
> /Eike
>
>
> Chris Lenz schrieb:
>> I tried this:
>> Organisation org =
>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>
>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>> help.saveToFile(obj,"c:\\test.organisation");
>>
>> That does not work??
>> Chris
>> Eike Stepper schrieb:
>>
>>> Chris,
>>>
>>> I think I know what happened to your exported objects. CDO generally
>>> loads objects on demand (even contained ones). Only the root objects
>>> are
>>> loaded together with the resource. That's why your root object is
>>> properly serialized to XMI. The contained objects (roles, users,
>>> processes) had not been loaded when you attached the root object to a
>>> different resource. The proxy URIs still apply to the CDO resource but
>>> that is no longer the container of the root. So they're not loaded
>>> anymore and don't get resolved.
>>>
>>> I really suggest that you EcoreUtil.copy() the CDO resource and attach
>>> the copy to the XMI resource.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Chris Lenz schrieb:
>>>
>>>> Hi eike,
>>>>
>>>> now I'am playing really a while with cdo and it is still cool.
>>>>
>>>> But I have one problem:
>>>>
>>>> I build a CDOHelper:
>>>> It can load a Resource from xmi file and save it to CDO.
>>>> But the otherway around is a bit tricky:
>>>> It always creates only something like the following:
>>>>
>>>> <?xml version="1.0" encoding="ASCII"?>
>>>> <organisation:Organisation xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>> name="test">
>>>> <roles href="cdo://2#2"/>
>>>> <roles href="cdo://2#3"/>
>>>> <roles href="cdo://2#4"/>
>>>> <roles href="cdo://2#5"/>
>>>> <roles href="cdo://2#6"/>
>>>> <users href="cdo://2#7"/>
>>>> <users href="cdo://2#8"/>
>>>> <users href="cdo://2#9"/>
>>>> <processes href="cdo://2#10"/>
>>>> <processes href="cdo://2#11"/>
>>>> <processes href="cdo://2#12"/>
>>>> </organisation:Organisation>
>>>>
>>>>
>>>> Thats the code?
>>>>
>>>> public void saveToFile(Organisation org, String string) {
>>>> try {
>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>
>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>> resourceSet.getPackageRegistry().put("organisation",
>>>> OrganisationPackage.eINSTANCE);
>>>> URI fileURI = URI.createFileURI(new File(string)
>>>> .getAbsolutePath());
>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>> poResource.getContents().add(org);
>>>> poResource.save(new HashMap());
>>>> } catch (Exception e) {
>>>> // TODO Auto-generated catch block
>>>> e.printStackTrace();
>>>> }
>>>>
>>>> }
>>>>

Re: CDO Resources [message #45631 is a reply to message #45604]

Mon, 21 August 2006 08:59

Eclipse User

Originally posted by: merks.ca.ibm.com

Eike,

By default, EcoreUtil.Copier should resolve proxies as it copies and
that should cause referenced resources to be loaded as necessary.

Eike Stepper wrote:

> Ed,
>
> I forgot to add you to the cc in the previous posting.
> There's a question for you ;-)
>
> Cheers
> /Eike
>
>
> Eike Stepper schrieb:
>
>> Chris,
>>
>> I've opened Bugzilla
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
>> The main outcome is that you have to use something like
>>
>> protected void preLoadResource(CDOResource cdoResource)
>> {
>> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
>> it.hasNext();)
>> {
>> CDOPersistable persistable = (CDOPersistable) it.next();
>> persistable.cdoLoad();
>> }
>> }
>>
>> before you try to copy the resource with EcoreUtil.
>>
>> I have to admit that I'm not completely sure about the influence of
>> resolveProxies during the copy process.
>> It seems that it does not automatically lead to loading
>> CDOPersistables that are proxies.
>> Ed: Could you explain a bit?
>>
>> Maybe CDO could override an EObject method so that resolving a proxy
>> would also load it.
>> At the moment cdoLoad is only called on explicit access to persistent
>> features.
>>
>> Cheers
>> /Eike
>>
>>
>> Chris Lenz schrieb:
>>
>>> I tried this:
>>> Organisation org =
>>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>>
>>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>>> help.saveToFile(obj,"c:\\test.organisation");
>>>
>>> That does not work??
>>> Chris
>>> Eike Stepper schrieb:
>>>
>>>
>>>> Chris,
>>>>
>>>> I think I know what happened to your exported objects. CDO generally
>>>> loads objects on demand (even contained ones). Only the root
>>>> objects are
>>>> loaded together with the resource. That's why your root object is
>>>> properly serialized to XMI. The contained objects (roles, users,
>>>> processes) had not been loaded when you attached the root object to a
>>>> different resource. The proxy URIs still apply to the CDO resource but
>>>> that is no longer the container of the root. So they're not loaded
>>>> anymore and don't get resolved.
>>>>
>>>> I really suggest that you EcoreUtil.copy() the CDO resource and attach
>>>> the copy to the XMI resource.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Chris Lenz schrieb:
>>>>
>>>>
>>>>> Hi eike,
>>>>>
>>>>> now I'am playing really a while with cdo and it is still cool.
>>>>>
>>>>> But I have one problem:
>>>>>
>>>>> I build a CDOHelper:
>>>>> It can load a Resource from xmi file and save it to CDO.
>>>>> But the otherway around is a bit tricky:
>>>>> It always creates only something like the following:
>>>>>
>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>> <organisation:Organisation xmi:version="2.0"
>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>>> name="test">
>>>>> <roles href="cdo://2#2"/>
>>>>> <roles href="cdo://2#3"/>
>>>>> <roles href="cdo://2#4"/>
>>>>> <roles href="cdo://2#5"/>
>>>>> <roles href="cdo://2#6"/>
>>>>> <users href="cdo://2#7"/>
>>>>> <users href="cdo://2#8"/>
>>>>> <users href="cdo://2#9"/>
>>>>> <processes href="cdo://2#10"/>
>>>>> <processes href="cdo://2#11"/>
>>>>> <processes href="cdo://2#12"/>
>>>>> </organisation:Organisation>
>>>>>
>>>>>
>>>>> Thats the code?
>>>>>
>>>>> public void saveToFile(Organisation org, String string) {
>>>>> try {
>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>
>>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>>> resourceSet.getPackageRegistry().put("organisation",
>>>>> OrganisationPackage.eINSTANCE);
>>>>> URI fileURI = URI.createFileURI(new File(string)
>>>>> .getAbsolutePath());
>>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>>> poResource.getContents().add(org);
>>>>> poResource.save(new HashMap());
>>>>> } catch (Exception e) {
>>>>> // TODO Auto-generated catch block
>>>>> e.printStackTrace();
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>

Re: CDO Resources [message #45661 is a reply to message #45631]

Mon, 21 August 2006 09:12

Eclipse User

Originally posted by: stepper.sympedia.de

Ed Merks schrieb:
> Eike,
>
> By default, EcoreUtil.Copier should resolve proxies as it copies and
> that should cause referenced resources to be loaded as necessary.
In this case it is only one resource.
CDO uses proxy URIs for contained objects, too.
I assume that resolving such proxies doesn't do anything, because the
resource is already loaded from a ResourceSet perspective.

Thx
/Eike

>
>
> Eike Stepper wrote:
>
>> Ed,
>>
>> I forgot to add you to the cc in the previous posting.
>> There's a question for you ;-)
>>
>> Cheers
>> /Eike
>>
>>
>> Eike Stepper schrieb:
>>
>>> Chris,
>>>
>>> I've opened Bugzilla
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
>>> The main outcome is that you have to use something like
>>>
>>> protected void preLoadResource(CDOResource cdoResource)
>>> {
>>> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
>>> it.hasNext();)
>>> {
>>> CDOPersistable persistable = (CDOPersistable) it.next();
>>> persistable.cdoLoad();
>>> }
>>> }
>>>
>>> before you try to copy the resource with EcoreUtil.
>>>
>>> I have to admit that I'm not completely sure about the influence of
>>> resolveProxies during the copy process.
>>> It seems that it does not automatically lead to loading
>>> CDOPersistables that are proxies.
>>> Ed: Could you explain a bit?
>>>
>>> Maybe CDO could override an EObject method so that resolving a proxy
>>> would also load it.
>>> At the moment cdoLoad is only called on explicit access to
>>> persistent features.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Chris Lenz schrieb:
>>>
>>>> I tried this:
>>>> Organisation org =
>>>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>>>
>>>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>>>> help.saveToFile(obj,"c:\\test.organisation");
>>>>
>>>> That does not work??
>>>> Chris
>>>> Eike Stepper schrieb:
>>>>
>>>>
>>>>> Chris,
>>>>>
>>>>> I think I know what happened to your exported objects. CDO generally
>>>>> loads objects on demand (even contained ones). Only the root
>>>>> objects are
>>>>> loaded together with the resource. That's why your root object is
>>>>> properly serialized to XMI. The contained objects (roles, users,
>>>>> processes) had not been loaded when you attached the root object to a
>>>>> different resource. The proxy URIs still apply to the CDO resource
>>>>> but
>>>>> that is no longer the container of the root. So they're not loaded
>>>>> anymore and don't get resolved.
>>>>>
>>>>> I really suggest that you EcoreUtil.copy() the CDO resource and
>>>>> attach
>>>>> the copy to the XMI resource.
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>>
>>>>> Chris Lenz schrieb:
>>>>>
>>>>>> Hi eike,
>>>>>>
>>>>>> now I'am playing really a while with cdo and it is still cool.
>>>>>>
>>>>>> But I have one problem:
>>>>>>
>>>>>> I build a CDOHelper:
>>>>>> It can load a Resource from xmi file and save it to CDO.
>>>>>> But the otherway around is a bit tricky:
>>>>>> It always creates only something like the following:
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <organisation:Organisation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>>>> name="test">
>>>>>> <roles href="cdo://2#2"/>
>>>>>> <roles href="cdo://2#3"/>
>>>>>> <roles href="cdo://2#4"/>
>>>>>> <roles href="cdo://2#5"/>
>>>>>> <roles href="cdo://2#6"/>
>>>>>> <users href="cdo://2#7"/>
>>>>>> <users href="cdo://2#8"/>
>>>>>> <users href="cdo://2#9"/>
>>>>>> <processes href="cdo://2#10"/>
>>>>>> <processes href="cdo://2#11"/>
>>>>>> <processes href="cdo://2#12"/>
>>>>>> </organisation:Organisation>
>>>>>>
>>>>>>
>>>>>> Thats the code?
>>>>>>
>>>>>> public void saveToFile(Organisation org, String string) {
>>>>>> try {
>>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>>
>>>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>>>> resourceSet.getPackageRegistry().put("organisation",
>>>>>> OrganisationPackage.eINSTANCE);
>>>>>> URI fileURI = URI.createFileURI(new File(string)
>>>>>> .getAbsolutePath());
>>>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>>>> poResource.getContents().add(org);
>>>>>> poResource.save(new HashMap());
>>>>>> } catch (Exception e) {
>>>>>> // TODO Auto-generated catch block
>>>>>> e.printStackTrace();
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>

Re: CDO Resources [message #45691 is a reply to message #45573]

Mon, 21 August 2006 09:15

Eclipse User

Originally posted by: stepper.sympedia.de

Chris,

The solution I outlined below will work, but is unefficient for large
resources.
It loads the resource object by object, each causing a signal to and
from the server.
If you want you can open an enhancement request asking for optimized
"Preloading Support".

Cheers
/Eike

Eike Stepper schrieb:
> Chris,
>
> I've opened Bugzilla
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
> The main outcome is that you have to use something like
>
> protected void preLoadResource(CDOResource cdoResource)
> {
> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
> it.hasNext();)
> {
> CDOPersistable persistable = (CDOPersistable) it.next();
> persistable.cdoLoad();
> }
> }
>
> before you try to copy the resource with EcoreUtil.
>
> I have to admit that I'm not completely sure about the influence of
> resolveProxies during the copy process.
> It seems that it does not automatically lead to loading
> CDOPersistables that are proxies.
> Ed: Could you explain a bit?
>
> Maybe CDO could override an EObject method so that resolving a proxy
> would also load it.
> At the moment cdoLoad is only called on explicit access to persistent
> features.
>
> Cheers
> /Eike
>
>
> Chris Lenz schrieb:
>> I tried this:
>> Organisation org =
>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>
>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>> help.saveToFile(obj,"c:\\test.organisation");
>>
>> That does not work??
>> Chris
>> Eike Stepper schrieb:
>>
>>> Chris,
>>>
>>> I think I know what happened to your exported objects. CDO generally
>>> loads objects on demand (even contained ones). Only the root objects
>>> are
>>> loaded together with the resource. That's why your root object is
>>> properly serialized to XMI. The contained objects (roles, users,
>>> processes) had not been loaded when you attached the root object to a
>>> different resource. The proxy URIs still apply to the CDO resource but
>>> that is no longer the container of the root. So they're not loaded
>>> anymore and don't get resolved.
>>>
>>> I really suggest that you EcoreUtil.copy() the CDO resource and attach
>>> the copy to the XMI resource.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Chris Lenz schrieb:
>>>
>>>> Hi eike,
>>>>
>>>> now I'am playing really a while with cdo and it is still cool.
>>>>
>>>> But I have one problem:
>>>>
>>>> I build a CDOHelper:
>>>> It can load a Resource from xmi file and save it to CDO.
>>>> But the otherway around is a bit tricky:
>>>> It always creates only something like the following:
>>>>
>>>> <?xml version="1.0" encoding="ASCII"?>
>>>> <organisation:Organisation xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>> name="test">
>>>> <roles href="cdo://2#2"/>
>>>> <roles href="cdo://2#3"/>
>>>> <roles href="cdo://2#4"/>
>>>> <roles href="cdo://2#5"/>
>>>> <roles href="cdo://2#6"/>
>>>> <users href="cdo://2#7"/>
>>>> <users href="cdo://2#8"/>
>>>> <users href="cdo://2#9"/>
>>>> <processes href="cdo://2#10"/>
>>>> <processes href="cdo://2#11"/>
>>>> <processes href="cdo://2#12"/>
>>>> </organisation:Organisation>
>>>>
>>>>
>>>> Thats the code?
>>>>
>>>> public void saveToFile(Organisation org, String string) {
>>>> try {
>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>
>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>> resourceSet.getPackageRegistry().put("organisation",
>>>> OrganisationPackage.eINSTANCE);
>>>> URI fileURI = URI.createFileURI(new File(string)
>>>> .getAbsolutePath());
>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>> poResource.getContents().add(org);
>>>> poResource.save(new HashMap());
>>>> } catch (Exception e) {
>>>> // TODO Auto-generated catch block
>>>> e.printStackTrace();
>>>> }
>>>>
>>>> }
>>>>

Re: CDO Resources [message #45724 is a reply to message #45661]

Mon, 21 August 2006 12:58

Eclipse User

Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------080402090308060800080703
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Eike,

Whenever a proxy is resolved, if the result is different from the
original object, it will replace the original, as in this EcoreEList method:

protected EObject resolve(int index, EObject eObject)
{
EObject resolved = resolveProxy(eObject);
if (resolved != eObject)
{
Object oldObject = data[index];
assign(index, validate(index, resolved));
didSet(index, resolved, oldObject);

So the code doesn't care whether it's in the same resource or not...

Eike Stepper wrote:

>
> Ed Merks schrieb:
>
>> Eike,
>>
>> By default, EcoreUtil.Copier should resolve proxies as it copies and
>> that should cause referenced resources to be loaded as necessary.
>
> In this case it is only one resource.
> CDO uses proxy URIs for contained objects, too.
> I assume that resolving such proxies doesn't do anything, because the
> resource is already loaded from a ResourceSet perspective.
>
> Thx
> /Eike
>
>
>>
>>
>> Eike Stepper wrote:
>>
>>> Ed,
>>>
>>> I forgot to add you to the cc in the previous posting.
>>> There's a question for you ;-)
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Eike Stepper schrieb:
>>>
>>>> Chris,
>>>>
>>>> I've opened Bugzilla
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
>>>> The main outcome is that you have to use something like
>>>>
>>>> protected void preLoadResource(CDOResource cdoResource)
>>>> {
>>>> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
>>>> it.hasNext();)
>>>> {
>>>> CDOPersistable persistable = (CDOPersistable) it.next();
>>>> persistable.cdoLoad();
>>>> }
>>>> }
>>>>
>>>> before you try to copy the resource with EcoreUtil.
>>>>
>>>> I have to admit that I'm not completely sure about the influence of
>>>> resolveProxies during the copy process.
>>>> It seems that it does not automatically lead to loading
>>>> CDOPersistables that are proxies.
>>>> Ed: Could you explain a bit?
>>>>
>>>> Maybe CDO could override an EObject method so that resolving a
>>>> proxy would also load it.
>>>> At the moment cdoLoad is only called on explicit access to
>>>> persistent features.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Chris Lenz schrieb:
>>>>
>>>>> I tried this:
>>>>> Organisation org =
>>>>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>>>>
>>>>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>>>>> help.saveToFile(obj,"c:\\test.organisation");
>>>>>
>>>>> That does not work??
>>>>> Chris
>>>>> Eike Stepper schrieb:
>>>>>
>>>>>
>>>>>> Chris,
>>>>>>
>>>>>> I think I know what happened to your exported objects. CDO generally
>>>>>> loads objects on demand (even contained ones). Only the root
>>>>>> objects are
>>>>>> loaded together with the resource. That's why your root object is
>>>>>> properly serialized to XMI. The contained objects (roles, users,
>>>>>> processes) had not been loaded when you attached the root object
>>>>>> to a
>>>>>> different resource. The proxy URIs still apply to the CDO
>>>>>> resource but
>>>>>> that is no longer the container of the root. So they're not loaded
>>>>>> anymore and don't get resolved.
>>>>>>
>>>>>> I really suggest that you EcoreUtil.copy() the CDO resource and
>>>>>> attach
>>>>>> the copy to the XMI resource.
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>>
>>>>>> Chris Lenz schrieb:
>>>>>>
>>>>>>
>>>>>>> Hi eike,
>>>>>>>
>>>>>>> now I'am playing really a while with cdo and it is still cool.
>>>>>>>
>>>>>>> But I have one problem:
>>>>>>>
>>>>>>> I build a CDOHelper:
>>>>>>> It can load a Resource from xmi file and save it to CDO.
>>>>>>> But the otherway around is a bit tricky:
>>>>>>> It always creates only something like the following:
>>>>>>>
>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>> <organisation:Organisation xmi:version="2.0"
>>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>>> xmlns:organisation="organisation"
>>>>>>> name="test">
>>>>>>> <roles href="cdo://2#2"/>
>>>>>>> <roles href="cdo://2#3"/>
>>>>>>> <roles href="cdo://2#4"/>
>>>>>>> <roles href="cdo://2#5"/>
>>>>>>> <roles href="cdo://2#6"/>
>>>>>>> <users href="cdo://2#7"/>
>>>>>>> <users href="cdo://2#8"/>
>>>>>>> <users href="cdo://2#9"/>
>>>>>>> <processes href="cdo://2#10"/>
>>>>>>> <processes href="cdo://2#11"/>
>>>>>>> <processes href="cdo://2#12"/>
>>>>>>> </organisation:Organisation>
>>>>>>>
>>>>>>>
>>>>>>> Thats the code?
>>>>>>>
>>>>>>> public void saveToFile(Organisation org, String string) {
>>>>>>> try {
>>>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>>>
>>>>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>>>>> resourceSet.getPackageRegistry().put("organisation",
>>>>>>> OrganisationPackage.eINSTANCE);
>>>>>>> URI fileURI = URI.createFileURI(new File(string)
>>>>>>> .getAbsolutePath());
>>>>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>>>>> poResource.getContents().add(org);
>>>>>>> poResource.save(new HashMap());
>>>>>>> } catch (Exception e) {
>>>>>>> // TODO Auto-generated catch block
>>>>>>> e.printStackTrace();
>>>>>>> }
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>
>>>>>>

--------------080402090308060800080703
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike, 
 
Whenever a proxy is resolved, if the result is different from the
original object, it will replace the original, as in this EcoreEList
method: 
<blockquote>

Re: CDO Resources [message #45996 is a reply to message #45691]

Tue, 22 August 2006 05:21

Eclipse User

We should use getAllProperContents instead of getAllContents

Now I am implementing the load and save action into the CDOExplorer.
Can I add this to repository, and how can I do this?
Chris
Eike Stepper schrieb:
> Chris,
>
> The solution I outlined below will work, but is unefficient for large
> resources.
> It loads the resource object by object, each causing a signal to and
> from the server.
> If you want you can open an enhancement request asking for optimized
> "Preloading Support".
>
> Cheers
> /Eike
>
>
> Eike Stepper schrieb:
>> Chris,
>>
>> I've opened Bugzilla
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
>> The main outcome is that you have to use something like
>>
>> protected void preLoadResource(CDOResource cdoResource)
>> {
>> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
>> it.hasNext();)
>> {
>> CDOPersistable persistable = (CDOPersistable) it.next();
>> persistable.cdoLoad();
>> }
>> }
>>
>> before you try to copy the resource with EcoreUtil.
>>
>> I have to admit that I'm not completely sure about the influence of
>> resolveProxies during the copy process.
>> It seems that it does not automatically lead to loading
>> CDOPersistables that are proxies.
>> Ed: Could you explain a bit?
>>
>> Maybe CDO could override an EObject method so that resolving a proxy
>> would also load it.
>> At the moment cdoLoad is only called on explicit access to persistent
>> features.
>>
>> Cheers
>> /Eike
>>
>>
>> Chris Lenz schrieb:
>>> I tried this:
>>> Organisation org =
>>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>>
>>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>>> help.saveToFile(obj,"c:\\test.organisation");
>>>
>>> That does not work??
>>> Chris
>>> Eike Stepper schrieb:
>>>
>>>> Chris,
>>>>
>>>> I think I know what happened to your exported objects. CDO generally
>>>> loads objects on demand (even contained ones). Only the root objects
>>>> are
>>>> loaded together with the resource. That's why your root object is
>>>> properly serialized to XMI. The contained objects (roles, users,
>>>> processes) had not been loaded when you attached the root object to a
>>>> different resource. The proxy URIs still apply to the CDO resource but
>>>> that is no longer the container of the root. So they're not loaded
>>>> anymore and don't get resolved.
>>>>
>>>> I really suggest that you EcoreUtil.copy() the CDO resource and attach
>>>> the copy to the XMI resource.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Chris Lenz schrieb:
>>>>
>>>>> Hi eike,
>>>>>
>>>>> now I'am playing really a while with cdo and it is still cool.
>>>>>
>>>>> But I have one problem:
>>>>>
>>>>> I build a CDOHelper:
>>>>> It can load a Resource from xmi file and save it to CDO.
>>>>> But the otherway around is a bit tricky:
>>>>> It always creates only something like the following:
>>>>>
>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>> <organisation:Organisation xmi:version="2.0"
>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>>> name="test">
>>>>> <roles href="cdo://2#2"/>
>>>>> <roles href="cdo://2#3"/>
>>>>> <roles href="cdo://2#4"/>
>>>>> <roles href="cdo://2#5"/>
>>>>> <roles href="cdo://2#6"/>
>>>>> <users href="cdo://2#7"/>
>>>>> <users href="cdo://2#8"/>
>>>>> <users href="cdo://2#9"/>
>>>>> <processes href="cdo://2#10"/>
>>>>> <processes href="cdo://2#11"/>
>>>>> <processes href="cdo://2#12"/>
>>>>> </organisation:Organisation>
>>>>>
>>>>>
>>>>> Thats the code?
>>>>>
>>>>> public void saveToFile(Organisation org, String string) {
>>>>> try {
>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>
>>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>>> resourceSet.getPackageRegistry().put("organisation",
>>>>> OrganisationPackage.eINSTANCE);
>>>>> URI fileURI = URI.createFileURI(new File(string)
>>>>> .getAbsolutePath());
>>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>>> poResource.getContents().add(org);
>>>>> poResource.save(new HashMap());
>>>>> } catch (Exception e) {
>>>>> // TODO Auto-generated catch block
>>>>> e.printStackTrace();
>>>>> }
>>>>>
>>>>> }
>>>>>

Re: CDO Resources [message #46026 is a reply to message #45996]

Tue, 22 August 2006 05:31

Eclipse User

preLoadResource loads only toplevel elements
myworkaround:
protected static void preLoadResource(CDOResource cdoResource) {
int i = 1;
int old = 0;
while (old < i) {
old = i;
i = 0;
for (Iterator it = EcoreUtil
.getAllProperContents(cdoResource, true); it.hasNext();) {
CDOPersistable persistable = (CDOPersistable) it.next();
persistable.cdoLoad();
i++;
}
}
}

Re: CDO Resources [message #46087 is a reply to message #45996]

Tue, 22 August 2006 07:06

Eclipse User

Originally posted by: stepper.sympedia.de

Chris,

If you send me a patch, I can review and apply it.

Cheers
/Eike

Chris Lenz schrieb:
> We should use getAllProperContents instead of getAllContents
>
> Now I am implementing the load and save action into the CDOExplorer.
> Can I add this to repository, and how can I do this?
> Chris
> Eike Stepper schrieb:
>> Chris,
>>
>> The solution I outlined below will work, but is unefficient for large
>> resources.
>> It loads the resource object by object, each causing a signal to and
>> from the server.
>> If you want you can open an enhancement request asking for optimized
>> "Preloading Support".
>>
>> Cheers
>> /Eike
>>
>>
>> Eike Stepper schrieb:
>>> Chris,
>>>
>>> I've opened Bugzilla
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
>>> The main outcome is that you have to use something like
>>>
>>> protected void preLoadResource(CDOResource cdoResource)
>>> {
>>> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
>>> it.hasNext();)
>>> {
>>> CDOPersistable persistable = (CDOPersistable) it.next();
>>> persistable.cdoLoad();
>>> }
>>> }
>>>
>>> before you try to copy the resource with EcoreUtil.
>>>
>>> I have to admit that I'm not completely sure about the influence of
>>> resolveProxies during the copy process.
>>> It seems that it does not automatically lead to loading
>>> CDOPersistables that are proxies.
>>> Ed: Could you explain a bit?
>>>
>>> Maybe CDO could override an EObject method so that resolving a proxy
>>> would also load it.
>>> At the moment cdoLoad is only called on explicit access to persistent
>>> features.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Chris Lenz schrieb:
>>>> I tried this:
>>>> Organisation org =
>>>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>>>
>>>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>>>> help.saveToFile(obj,"c:\\test.organisation");
>>>>
>>>> That does not work??
>>>> Chris
>>>> Eike Stepper schrieb:
>>>>
>>>>> Chris,
>>>>>
>>>>> I think I know what happened to your exported objects. CDO generally
>>>>> loads objects on demand (even contained ones). Only the root objects
>>>>> are
>>>>> loaded together with the resource. That's why your root object is
>>>>> properly serialized to XMI. The contained objects (roles, users,
>>>>> processes) had not been loaded when you attached the root object to a
>>>>> different resource. The proxy URIs still apply to the CDO resource but
>>>>> that is no longer the container of the root. So they're not loaded
>>>>> anymore and don't get resolved.
>>>>>
>>>>> I really suggest that you EcoreUtil.copy() the CDO resource and attach
>>>>> the copy to the XMI resource.
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>>
>>>>> Chris Lenz schrieb:
>>>>>
>>>>>> Hi eike,
>>>>>>
>>>>>> now I'am playing really a while with cdo and it is still cool.
>>>>>>
>>>>>> But I have one problem:
>>>>>>
>>>>>> I build a CDOHelper:
>>>>>> It can load a Resource from xmi file and save it to CDO.
>>>>>> But the otherway around is a bit tricky:
>>>>>> It always creates only something like the following:
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <organisation:Organisation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>>>> name="test">
>>>>>> <roles href="cdo://2#2"/>
>>>>>> <roles href="cdo://2#3"/>
>>>>>> <roles href="cdo://2#4"/>
>>>>>> <roles href="cdo://2#5"/>
>>>>>> <roles href="cdo://2#6"/>
>>>>>> <users href="cdo://2#7"/>
>>>>>> <users href="cdo://2#8"/>
>>>>>> <users href="cdo://2#9"/>
>>>>>> <processes href="cdo://2#10"/>
>>>>>> <processes href="cdo://2#11"/>
>>>>>> <processes href="cdo://2#12"/>
>>>>>> </organisation:Organisation>
>>>>>>
>>>>>>
>>>>>> Thats the code?
>>>>>>
>>>>>> public void saveToFile(Organisation org, String string) {
>>>>>> try {
>>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>>
>>>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>>>> resourceSet.getPackageRegistry().put("organisation",
>>>>>> OrganisationPackage.eINSTANCE);
>>>>>> URI fileURI = URI.createFileURI(new File(string)
>>>>>> .getAbsolutePath());
>>>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>>>> poResource.getContents().add(org);
>>>>>> poResource.save(new HashMap());
>>>>>> } catch (Exception e) {
>>>>>> // TODO Auto-generated catch block
>>>>>> e.printStackTrace();
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>

Re: CDO Resources [message #46117 is a reply to message #46026]

Tue, 22 August 2006 07:14

Eclipse User

Originally posted by: stepper.sympedia.de

Chris Lenz schrieb:
> preLoadResource loads only toplevel elements

My proposal for a preLoadResource loads all objects contained in that resource.
I verified this with a test case.
If your resource does not get fully loaded, please explain a bit more.

> myworkaround:
> protected static void preLoadResource(CDOResource cdoResource) {
> int i = 1;
> int old = 0;
> while (old < i) {
> old = i;
> i = 0;
> for (Iterator it = EcoreUtil
> .getAllProperContents(cdoResource, true); it.hasNext();) {
> CDOPersistable persistable = (CDOPersistable) it.next();
> persistable.cdoLoad();
> i++;
> }
> }
> }

This seems a bit of a brute force ;-)
The effort can be O(n*n) where n is the number of objects in the resource.

Cheers
/Eike

Re: CDO Resources [message #46147 is a reply to message #46117]

Tue, 22 August 2006 09:22

Eclipse User

Ok in my case it loads not objects contained in that resource, I try to
explain.

If the resource looks like the following:
toplevelElement
-subelement
-subsubelement
-subsubsubelement
-subelement
-subsubelement
-subsubsubelement

in the first iteration it loads the toplevelelement and all subelements.

in the next iteration it loads on level more, it loads also the
subsubelements.
and so on.

I hope that's understandable!

Yes it's like bruteforce, it's horrible :-)
Chris

Eike Stepper schrieb:
> Chris Lenz schrieb:
>> preLoadResource loads only toplevel elements
>
> My proposal for a preLoadResource loads all objects contained in that
> resource.
> I verified this with a test case.
> If your resource does not get fully loaded, please explain a bit more.
>
>
>> myworkaround:
>> protected static void preLoadResource(CDOResource cdoResource) {
>> int i = 1;
>> int old = 0;
>> while (old < i) {
>> old = i;
>> i = 0;
>> for (Iterator it = EcoreUtil
>> .getAllProperContents(cdoResource, true);
>> it.hasNext();) {
>> CDOPersistable persistable = (CDOPersistable) it.next();
>> persistable.cdoLoad();
>> i++;
>> }
>> }
>> }
>
> This seems a bit of a brute force ;-)
> The effort can be O(n*n) where n is the number of objects in the resource.
>
> Cheers
> /Eike

Re: CDO Resources [message #46293 is a reply to message #46147]

Tue, 22 August 2006 11:39

Eclipse User

Originally posted by: stepper.sympedia.de

Chris Lenz schrieb:
> Ok in my case it loads not objects contained in that resource, I try to
> explain.
>
> If the resource looks like the following:
> toplevelElement
> -subelement
> -subsubelement
> -subsubsubelement
> -subelement
> -subsubelement
> -subsubsubelement
>
> in the first iteration it loads the toplevelelement and all subelements.
>
> in the next iteration it loads on level more, it loads also the
> subsubelements.
> and so on.
>
> I hope that's understandable!

I already understood that your method works like that ;-)
But I asked you to explain, what exactly did not work with my method.
As I said, it works for me (and performs better than yours).
Can you provide a zip with the source code that you used to test my method?

Cheers
/Eike

Re: CDO Resources [message #46323 is a reply to message #46293]

Wed, 23 August 2006 04:15

Eclipse User

This your model have more than two levels.

My application is very complex, but I try to create some easier.
Chris
Eike Stepper schrieb:
> Chris Lenz schrieb:
>> Ok in my case it loads not objects contained in that resource, I try to
>> explain.
>>
>> If the resource looks like the following:
>> toplevelElement
>> -subelement
>> -subsubelement
>> -subsubsubelement
>> -subelement
>> -subsubelement
>> -subsubsubelement
>>
>> in the first iteration it loads the toplevelelement and all subelements.
>>
>> in the next iteration it loads on level more, it loads also the
>> subsubelements.
>> and so on.
>>
>> I hope that's understandable!
>
> I already understood that your method works like that ;-)
> But I asked you to explain, what exactly did not work with my method.
> As I said, it works for me (and performs better than yours).
> Can you provide a zip with the source code that you used to test my method?
>
> Cheers
> /Eike
>

Re: CDO Resources [message #46384 is a reply to message #46323]

Wed, 23 August 2006 05:54

Eclipse User

Originally posted by: stepper.sympedia.de

Chris,

Please don't spend any more effort for constructing an example!
I could reproduce your issue in /org.eclipse.emf.cdo.tests/src/org/eclipse/emf/cdo/tests/mod el1/SerializationTest.java
Look for testExportThreeLevels().

The issue is caused because EObject.eContents() does not call cdoLoad().
I've fixed this in CDOPersistentImpl:

/**
* @ADDED
*/
@Override
public EList eContents()
{
cdoLoad();
return super.eContents();
}

The changes are committed to CVS.
Can you please verify that it works for you?

Cheers
/Eike

Chris Lenz schrieb:
> This your model have more than two levels.
>
> My application is very complex, but I try to create some easier.
> Chris
> Eike Stepper schrieb:
>> Chris Lenz schrieb:
>>> Ok in my case it loads not objects contained in that resource, I try to
>>> explain.
>>>
>>> If the resource looks like the following:
>>> toplevelElement
>>> -subelement
>>> -subsubelement
>>> -subsubsubelement
>>> -subelement
>>> -subsubelement
>>> -subsubsubelement
>>>
>>> in the first iteration it loads the toplevelelement and all subelements.
>>>
>>> in the next iteration it loads on level more, it loads also the
>>> subsubelements.
>>> and so on.
>>>
>>> I hope that's understandable!
>> I already understood that your method works like that ;-)
>> But I asked you to explain, what exactly did not work with my method.
>> As I said, it works for me (and performs better than yours).
>> Can you provide a zip with the source code that you used to test my method?
>>
>> Cheers
>> /Eike
>>

Re: CDO Resources [message #48451 is a reply to message #45455]

Mon, 04 September 2006 12:48

Eclipse User

This is a multi-part message in MIME format.
--------------020300090008000205060502
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Import Export Button patch:
Would it be possible to implement the delete function for the cdo
resources? Can I do it myself, where have I to look for??
Thanx Chris

Eike Stepper schrieb:
> Chris,
>
> If you think that import and export buttons in the CDO Explorer are a
> good idea, please feel free to open an enhancement request.
>
> Cheers
> /Eike
>
>
> Chris Lenz schrieb:
>> Hi eike,
>>
>> now I'am playing really a while with cdo and it is still cool.
>>
>> But I have one problem:
>>
>> I build a CDOHelper:
>> It can load a Resource from xmi file and save it to CDO.
>> But the otherway around is a bit tricky:
>> It always creates only something like the following:
>>
>> <?xml version="1.0" encoding="ASCII"?>
>> <organisation:Organisation xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>> name="test">
>> <roles href="cdo://2#2"/>
>> <roles href="cdo://2#3"/>
>> <roles href="cdo://2#4"/>
>> <roles href="cdo://2#5"/>
>> <roles href="cdo://2#6"/>
>> <users href="cdo://2#7"/>
>> <users href="cdo://2#8"/>
>> <users href="cdo://2#9"/>
>> <processes href="cdo://2#10"/>
>> <processes href="cdo://2#11"/>
>> <processes href="cdo://2#12"/>
>> </organisation:Organisation>
>>
>>
>> Thats the code?
>>
>> public void saveToFile(Organisation org, String string) {
>> try {
>> ResourceSet resourceSet = new ResourceSetImpl();
>>
>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>> .put("organisation", new XMIResourceFactoryImpl());
>> resourceSet.getPackageRegistry().put("organisation",
>> OrganisationPackage.eINSTANCE);
>> URI fileURI = URI.createFileURI(new File(string)
>> .getAbsolutePath());
>> Resource poResource = resourceSet.createResource(fileURI);
>> poResource.getContents().add(org);
>>
>> poResource.save(new HashMap());
>> } catch (Exception e) {
>> // TODO Auto-generated catch block
>> e.printStackTrace();
>> }
>>
>> }
>>

--------------020300090008000205060502
Content-Type: text/plain;
name="patch.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
filename="patch.txt"

### Eclipse Workspace Patch 1.0
#P org.eclipse.emf.cdo.examples.ui
Index: src/org/eclipse/emf/cdo/examples/ui/internal/UIUtils.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/technology/org.eclipse.emft/cdo/examples/org.eclips e.e=
mf.cdo.examples.ui/src/org/eclipse/emf/cdo/examples/ui/inter nal/UIUtils.j=
ava,v
retrieving revision 1.7
diff -u -r1.7 UIUtils.java
--- src/org/eclipse/emf/cdo/examples/ui/internal/UIUtils.java 1 Sep 2006 =
10:00:09 -0000 1.7
+++ src/org/eclipse/emf/cdo/examples/ui/internal/UIUtils.java 4 Sep 2006 =
16:45:42 -0000
@@ -10,19 +10,36 @@
************************************************************ ***********=
***/
package org.eclipse.emf.cdo.examples.ui.internal;
=20
+import java.io.File;
+import java.util.HashMap;
+import java.util.Iterator;
=20
+import org.eclipse.emf.cdo.client.CDOPersistable;
+import org.eclipse.emf.cdo.client.CDOResource;
import org.eclipse.emf.cdo.client.ResourceInfo;
import org.eclipse.emf.cdo.client.ResourceManager;
+import org.eclipse.emf.cdo.examples.client.internal.ExampleClientPl ugin;=

import org.eclipse.emf.cdo.examples.ui.internal.editors.CDOEditor;
import org.eclipse.emf.cdo.examples.ui.internal.editors.CDOEditorIn put;
import org.eclipse.emf.cdo.examples.ui.internal.wizards.CDONewWizar d;
+import org.eclipse.emf.common.util.URI;
+import org.eclipse.emf.ecore.EObject;
+import org.eclipse.emf.ecore.resource.Resource;
+import org.eclipse.emf.ecore.resource.ResourceSet;
+import org.eclipse.emf.ecore.resource.impl.ResourceSetImpl;
+import org.eclipse.emf.ecore.util.EcoreUtil;
import org.eclipse.emf.edit.ui.provider.ExtendedImageRegistry;
+import org.eclipse.jface.dialogs.IInputValidator;
+import org.eclipse.jface.dialogs.InputDialog;
import org.eclipse.jface.dialogs.MessageDialog;
import org.eclipse.jface.resource.ImageDescriptor;
import org.eclipse.jface.viewers.Viewer;
+import org.eclipse.jface.window.Window;
import org.eclipse.jface.wizard.WizardDialog;
+import org.eclipse.swt.SWT;
import org.eclipse.swt.graphics.Image;
import org.eclipse.swt.widgets.Display;
+import org.eclipse.swt.widgets.FileDialog;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.ui.IEditorPart;
import org.eclipse.ui.IWorkbench;
@@ -30,102 +47,201 @@
import org.eclipse.ui.IWorkbenchWindow;
import org.eclipse.ui.PartInitException;
import org.eclipse.ui.PlatformUI;
+import org.eclipse.ui.internal.Workbench;
import org.eclipse.ui.views.properties.IPropertySheetPage;
import org.eclipse.ui.views.properties.PropertySheetPage;
=20
-
-public class UIUtils
-{
- public static void openCDONewWizard(ResourceManager resourceManager, b=
oolean commit)
- {
- CDONewWizard wizard =3D new CDONewWizard(resourceManager, commit);
- wizard.init(PlatformUI.getWorkbench(), null);
- wizard.setNeedsProgressMonitor(true);
-
- WizardDialog dialog =3D new WizardDialog(new Shell(), wizard);
- dialog.create();
- dialog.open();
- }
-
- public static void openCDONewWizard()
- {
- openCDONewWizard(null, true);
- }
-
- public static IEditorPart openCDOEditor(ResourceInfo resourceInfo)
- {
- IWorkbench workbench =3D PlatformUI.getWorkbench();
- IWorkbenchWindow activeWorkbenchWindow =3D workbench.getActiveWorkbe=
nchWindow();
- IWorkbenchPage activePage =3D activeWorkbenchWindow.getActivePage();=

-
- try
- {
- return activePage.openEditor(new CDOEditorInput(resourceInfo), CDO=
Editor.EDITOR_ID);
- }
- catch (PartInitException ex)
- {
- MessageDialog.openError(new Shell(), "CDO Explorer", "Can't open C=
DO Editor for "
- + resourceInfo);
- return null;
- }
- }
-
- public static ImageDescriptor getImageDescriptor(String key)
- {
- return ExtendedImageRegistry.getInstance().getImageDescriptor(
- ExampleUIActivator.INSTANCE.getImage(key));
- }
-
- public static Image getImage(String key)
- {
- return ExtendedImageRegistry.getInstance().getImage(ExampleUIActiva t=
or.INSTANCE.getImage(key));
- }
-
- public static void refreshViewer(final Viewer viewer)
- {
- Display display =3D viewer.getControl().getDisplay();
- display.asyncExec(new Runnable()
- {
- public void run()
- {
- if (viewer !=3D null && !viewer.getControl().isDisposed())
- {
- try
- {
- viewer.refresh();
- }
- catch (Exception ex)
- {
- ex.printStackTrace();
- }
- }
- }
- });
- }
-
- public static void refreshPropertySheetPage(final IPropertySheetPage p=
ropertySheetPage)
- {
- if (propertySheetPage instanceof PropertySheetPage)
- {
- final PropertySheetPage page =3D (PropertySheetPage)propertySheetP=
age;
- Display display =3D page.getControl().getDisplay();
- display.asyncExec(new Runnable()
- {
- public void run()
- {
- if (page !=3D null && !page.getControl().isDisposed())
- {
- try
- {
- page.refresh();
- }
- catch (Exception ex)
- {
- ex.printStackTrace();
- }
- }
- }
- });
- }
- }
+public class UIUtils {
+ public static void openCDONewWizard(ResourceManager resourceManager,
+ boolean commit) {
+ CDONewWizard wizard =3D new CDONewWizard(resourceManager, commit);
+ wizard.init(PlatformUI.getWorkbench(), null);
+ wizard.setNeedsProgressMonitor(true);
+
+ WizardDialog dialog =3D new WizardDialog(new Shell(), wizard);
+ dialog.create();
+ dialog.open();
+ }
+
+ public static void openCDONewWizard() {
+ openCDONewWizard(null, true);
+ }
+
+ public static IEditorPart openCDOEditor(ResourceInfo resourceInfo) {
+ IWorkbench workbench =3D PlatformUI.getWorkbench();
+ IWorkbenchWindow activeWorkbenchWindow =3D workbench
+ .getActiveWorkbenchWindow();
+ IWorkbenchPage activePage =3D activeWorkbenchWindow.getActivePage();
+
+ try {
+ return activePage.openEditor(new CDOEditorInput(resourceInfo),
+ CDOEditor.EDITOR_ID);
+ } catch (PartInitException ex) {
+ MessageDialog.openError(new Shell(), "CDO Explorer",
+ "Can't open CDO Editor for " + resourceInfo);
+ return null;
+ }
+ }
+
+ public static ImageDescriptor getImageDescriptor(String key) {
+ return ExtendedImageRegistry.getInstance().getImageDescriptor(
+ ExampleUIActivator.INSTANCE.getImage(key));
+ }
+
+ public static Image getImage(String key) {
+ return ExtendedImageRegistry.getInstance().getImage(
+ ExampleUIActivator.INSTANCE.getImage(key));
+ }
+
+ public static void importCDOResource() {
+ try {
+ ResourceSet resourceSet =3D new ResourceSetImpl();
+
+ Shell shell =3D Workbench.getInstance().getActiveWorkbenchWindow()
+ .getActivePage().getActivePart().getSite().getShell();
+ FileDialog fileChooser =3D new FileDialog(shell, SWT.SAVE);
+ String fileName =3D fileChooser.open();
+
+ if (fileName =3D=3D null) {
+ return;
+ }
+
+ URI fileURI =3D URI.createFileURI(new File(fileName)
+ .getAbsolutePath());
+ Resource poResource =3D resourceSet.getResource(fileURI, true);
+ EObject org =3D (EObject) poResource.getContents().get(0);
+ createSampleResource(org);
+ } catch (Exception e) {
+ e.printStackTrace();
+ }
+ }
+
+ private static void createSampleResource(EObject org) {
+ Shell shell =3D Workbench.getInstance().getActiveWorkbenchWindow()
+ .getActivePage().getActivePart().getSite().getShell();
+ InputDialog d =3D new InputDialog(shell, "Resource Name",
+ "Geben sie den Resource Name ein", "cdo:///",
+ new CDOValidator());
+ if (d.open() =3D=3D Window.OK) {
+ ResourceSet resourceSet =3D new ResourceSetImpl();
+ ResourceManager resourceManager =3D ExampleClientPlugin
+ .createResourceManager(resourceSet);
+ CDOResource resource =3D (CDOResource) resourceSet.createResource(URI=

+ .createURI(d.getValue()));
+
+ resource.getContents().add(org);
+ resourceManager.commit();
+ }
+ }
+ public static void saveCDOResource(ResourceInfo info) {
+ try {
+ EObject obj =3D loadFromRepository(info);
+ ResourceSet resourceSet =3D new ResourceSetImpl();
+ /*
+ * resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap=
()
+ * .put("xmi", new XMIResourceFactoryImpl());
+ */
+
+ /*
+ * resourceSet.getPackageRegistry().put(
+ * obj.eClass().getEPackage().getNsURI(),
+ * obj.eClass().getEPackage());
+ */
+
+ Shell shell =3D Workbench.getInstance().getActiveWorkbenchWindow()
+ .getActivePage().getActivePart().getSite().getShell();
+ FileDialog fileChooser =3D new FileDialog(shell, SWT.SAVE);
+ String fileName =3D fileChooser.open();
+
+ if (fileName =3D=3D null) {
+ return;
+ }
+
+ URI fileURI =3D URI.createFileURI(new File(fileName)
+ .getAbsolutePath());
+ Resource poResource =3D resourceSet.createResource(fileURI);
+ poResource.getContents().add(obj);
+ poResource.save(new HashMap());
+ } catch (Exception e) {
+ // TODO Auto-generated catch block
+ e.printStackTrace();
+ }
+
+ }
+ private static EObject loadFromRepository(ResourceInfo info) {
+ ResourceSet resourceSet =3D new ResourceSetImpl();
+ ResourceManager resourceManager =3D ExampleClientPlugin
+ .createResourceManager(resourceSet);
+ CDOResource resource =3D (CDOResource) resourceSet.getResource(URI
+ .createURI(getResourceURI(info)), true);
+ EObject org =3D (EObject) resource.getContents().get(0);
+ preLoadResource(resource);
+ return org;
+ }
+ private static String getResourceURI(ResourceInfo resourceInfo) {
+ return "cdo://" + resourceInfo.getPath();
+ }
+ private static void preLoadResource(CDOResource cdoResource) {
+ int i =3D 1;
+ int old =3D 0;
+ while (old < i) {
+ old =3D i;
+ i =3D 0;
+ for (Iterator it =3D EcoreUtil
+ .getAllProperContents(cdoResource, true); it.hasNext();) {
+ CDOPersistable persistable =3D (CDOPersistable) it.next();
+ persistable.cdoLoad();
+ i++;
+ }
+ }
+ }
+ static class CDOValidator implements IInputValidator {
+
+ /**
+ * Validates the String. Returns null for no error, or an error messag=
e
+ *=20
+ * @param newText
+ * the String to validate
+ * @return String
+ */
+ public String isValid(String newText) {
+ if (newText.startsWith("cdo:///")) {
+ return null;
+ } else
+ return "must start with cdo:///";
+ }
+ }
+ public static void refreshViewer(final Viewer viewer) {
+ Display display =3D viewer.getControl().getDisplay();
+ display.asyncExec(new Runnable() {
+ public void run() {
+ if (viewer !=3D null && !viewer.getControl().isDisposed()) {
+ try {
+ viewer.refresh();
+ } catch (Exception ex) {
+ ex.printStackTrace();
+ }
+ }
+ }
+ });
+ }
+
+ public static void refreshPropertySheetPage(
+ final IPropertySheetPage propertySheetPage) {
+ if (propertySheetPage instanceof PropertySheetPage) {
+ final PropertySheetPage page =3D (PropertySheetPage) propertySheetPag=
e;
+ Display display =3D page.getControl().getDisplay();
+ display.asyncExec(new Runnable() {
+ public void run() {
+ if (page !=3D null && !page.getControl().isDisposed()) {
+ try {
+ page.refresh();
+ } catch (Exception ex) {
+ ex.printStackTrace();
+ }
+ }
+ }
+ });
+ }
+ }
}
Index: src/org/eclipse/emf/cdo/examples/ui/internal/views/CDOExplor er.jav=
a
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/technology/org.eclipse.emft/cdo/examples/org.eclips e.e=
mf.cdo.examples.ui/src/org/eclipse/emf/cdo/examples/ui/inter nal/views/CDO=
Explorer.java,v
retrieving revision 1.6
diff -u -r1.6 CDOExplorer.java
--- src/org/eclipse/emf/cdo/examples/ui/internal/views/CDOExplor er.java 1=
Sep 2006 10:00:09 -0000 1.6
+++ src/org/eclipse/emf/cdo/examples/ui/internal/views/CDOExplor er.java 4=
Sep 2006 16:45:42 -0000
@@ -17,6 +17,7 @@
import org.eclipse.emf.cdo.examples.ui.internal.ResourceLabelProvid er;
import org.eclipse.emf.cdo.examples.ui.internal.UIUtils;
import org.eclipse.emf.cdo.examples.ui.internal.actions.CDOCreateRe sourc=
eAction;
+import org.eclipse.emf.ecore.EObject;
import org.eclipse.jface.action.Action;
import org.eclipse.jface.action.IMenuListener;
import org.eclipse.jface.action.IMenuManager;
@@ -51,6 +52,10 @@
private Action deleteResourceAction;
=20
private Action openResourceAction;
+ =20
+ private Action importResourceAction;
+ =20
+ private Action exportResourceAction;
=20
// private Channel cdoResChannel;
=20
@@ -115,6 +120,8 @@
{
manager.add(newResourceAction);
manager.add(deleteResourceAction);
+ manager.add(exportResourceAction);
+ manager.add(importResourceAction);
manager.add(new Separator());
// Other plug-ins can contribute there actions here
manager.add(new Separator(IWorkbenchActionConstants.MB_ADDITIONS));
@@ -123,7 +130,7 @@
private void fillLocalToolBar(IToolBarManager manager)
{
manager.add(newResourceAction);
- manager.add(deleteResourceAction);
+ manager.add(deleteResourceAction); =20
}
=20
private void makeActions()
@@ -154,9 +161,44 @@
}
}
};
+ importResourceAction =3D new Action()
+ {
+ public void run()
+ {
+ ISelection selection =3D viewer.getSelection();
+ Object obj =3D ((IStructuredSelection)selection).getFirstElement=
();
+ UIUtils.importCDOResource();
+
+ }
+ };=20
+ importResourceAction.setText("Import CDO Resource");
+ importResourceAction.setToolTipText("Import CDO Resource");
+ importResourceAction.setImageDescriptor(UIUtils
+ .getImageDescriptor("full/ctool16/ImportCDOResource"));
+ exportResourceAction =3D new Action()
+ {
+ public void run()
+ {
+ ISelection selection =3D viewer.getSelection();
+ Object obj =3D ((IStructuredSelection)selection).getFirstElement=
();
+ if (obj instanceof ResourceInfo)
+ {
+ UIUtils.saveCDOResource((ResourceInfo)obj);
+ }
+ }
+ };=20
+ exportResourceAction.setText("Export CDO Resource");
+ exportResourceAction.setToolTipText("Export CDO Resource");
+ exportResourceAction.setImageDescriptor(UIUtils
+ .getImageDescriptor("full/ctool16/SaveCDOResource"));
}
=20
- private void hookDoubleClickAction()
+ private static EObject loadFromRepository(ResourceInfo info) {
+ // TODO Auto-generated method stub
+ return null;
+}
+
+private void hookDoubleClickAction()
{
viewer.addDoubleClickListener(new IDoubleClickListener()
{
@@ -176,4 +218,4 @@
{
viewer.getControl().setFocus();
}
-}
+}
\ No newline at end of file
Index: icons/full/ctool16/ImportCDOResource.gif
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: icons/full/ctool16/ImportCDOResource.gif
diff -N icons/full/ctool16/ImportCDOResource.gif
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ icons/full/ctool16/ImportCDOResource.gif 1 Jan 1970 00:00:00 -0000
@@ -0,0 +1,4 @@
+GIF89a=10=00=10=00=C6N=00,u=BA+|=AFyn>zn>zn?zo>zo?&=84=BA}o > =88=C4?q=3D=
=1D=8C=CB=85u<^v=A3=17=94=D5=8Bw;=14=98=DCcz=A7?z9<=89=D08=8C=D4f~=A8;?=D3=
=96|8j=82=ACm=84=AD=A0=825=A5=844q=88=B1s=89=B2=AA=863=AE=88 1=BF=7F?=B2=8A=
0|=92=B8~=93=BAE=A9=E9?=97=BC=84=9A=BFi=A4=DB=8C=A0=C3r=A9=D Cw=AA=D1r=AB=DC=
=BF=9F_v=AD=DC=91=A5=C7=85=B2=E1=83=B4=E1=FF=9F?=94=BC=E4=9C =C7=F0=FF=BF?=
=AF=D8=F7=FF=DF?=DC=E7=F7=DD=E7=F7=DE=E8=F7=DE=E8=F8=DF=E8=F 7=E1=EA=F8=E4=
=EC=F9=E6=EE=F9=E7=EE=F9=FF=FF_=EA=F0=F9=FF=FF=7F=ED=F2=FA=F 0=F5=FB=F2=F5=
=FB=F3=F5=FB=F2=F6=FB=F3=F6=FB=F5=F8=FB=F7=F9=FB=F8=F9=FB=F8 =F9=FC=F9=FA=FC=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
!=F9=04=01=00=00=7F=00,=00=00=00=00=10=00=10=00=00=07=A9=80= 7F=82=83=84=85=
=84!=88=89=88,, =85!M=91=924,B 4=84=1FJLK=9B=8C1@ =A2=83=1EI.%=19
+=95@@66=8E=82=1BEHGHF=A2 =AF=A3=82=1AD.(&"=1D4=B9=97=82$'53+$C=CEC=B8=83=
=10=142/=13=10=C1=1D=18=11A=17=83=0E)=CA+=0E?=E5?>?=12=83=0B=E1=CB=0B=D9=DB=
=3D=0F=83 =ED+ <=F9=FA=0C=83=07=F6=07#8T=D8=91C=87=82A=01,=C0ha!=C0
+=1C=0F!"=18=A4=02=C0B=0B*=0C=14( =A0=00?=01=86B=16
+=04=00;
Index: icons/full/ctool16/SaveCDOResource.gif
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: icons/full/ctool16/SaveCDOResource.gif
diff -N icons/full/ctool16/SaveCDOResource.gif
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ icons/full/ctool16/SaveCDOResource.gif 1 Jan 1970 00:00:00 -0000
@@ -0,0 +1,4 @@
+GIF89a=10=00=10=00=C6N=00,u=BA+|=AFyn>zn>zn?zo>zo?&=84=BA}o > =88=C4?q=3D=
=1D=8C=CB=85u<^v=A3=17=94=D5=8Bw;=14=98=DCcz=A7?z9<=89=D08=8C=D4f~=A8;?=D3=
=96|8j=82=ACm=84=AD=A0=825=A5=844q=88=B1s=89=B2=AA=863=AE=88 1=BF=7F?=B2=8A=
0|=92=B8~=93=BAE=A9=E9?=97=BC=84=9A=BFi=A4=DB=8C=A0=C3r=A9=D Cw=AA=D1r=AB=DC=
=BF=9F_v=AD=DC=91=A5=C7=85=B2=E1=83=B4=E1=FF=9F?=94=BC=E4=9C =C7=F0=FF=BF?=
=AF=D8=F7=FF=DF?=DC=E7=F7=DD=E7=F7=DE=E8=F7=DE=E8=F8=DF=E8=F 7=E1=EA=F8=E4=
=EC=F9=E6=EE=F9=E7=EE=F9=FF=FF_=EA=F0=F9=FF=FF=7F=ED=F2=FA=F 0=F5=FB=F2=F5=
=FB=F3=F5=FB=F2=F6=FB=F3=F6=FB=F5=F8=FB=F7=F9=FB=F8=F9=FB=F8 =F9=FC=F9=FA=FC=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF =FF=FF=FF=FF=FF=
!=F9=04=01=00=00=7F=00,=00=00=00=00=10=00=10=00=00=07=A9=80= 7F=82=83=84=85=
=84!=88=89=88,, =85!M=91=924,B 4=84=1FJLK=9B=8C1@ =A2=83=1EI.%=19
+=95@@66=8E=82=1BEHGHF=A2 =AF=A3=82=1AD.(&"=1D4=B9=97=82$'53+$C=CEC=B8=83=
=10=142/=13=10=C1=1D=18=11A=17=83=0E)=CA+=0E?=E5?>?=12=83=0B=E1=CB=0B=D9=DB=
=3D=0F=83 =ED+ <=F9=FA=0C=83=07=F6=07#8T=D8=91C=87=82A=01,=C0ha!=C0
+=1C=0F!"=18=A4=02=C0B=0B*=0C=14( =A0=00?=01=86B=16
+=04=00;

--------------020300090008000205060502--

Re: CDO Resources [message #48780 is a reply to message #48451]

Tue, 05 September 2006 12:23

Eclipse User

Originally posted by: stepper.sympedia.de

Chris,

I'm currently working on this bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=156162
I can't open the import/export icons in your patch.
Can you please attach them directly to this newsgroup thread?

Cheers
/Eike

Chris Lenz schrieb:
> Import Export Button patch:
> Would it be possible to implement the delete function for the cdo
> resources? Can I do it myself, where have I to look for??
> Thanx Chris

Re: CDO Resources [message #48867 is a reply to message #48451]

Wed, 06 September 2006 15:20

Eclipse User

Originally posted by: stepper.sympedia.de

Chris,

The CVS HEAD version addresses both enhancements, import/export and delete.
You can alternatively download zips from

http://emft.eclipse.org/technology/emft/downloads/downloads- viewer.php?proj=cdo&s=1.0.0/N200609061442/

I'd appreciate if you could verify that the new features satisfy your needs.
There is a remaining issue with CDOEditors that still have resources already
deleted by other sessions, but I will fix that in another Bugzilla.

Btw. resource deletions have been rather complicated to implement because
objects in other resources can be affected by this operation. The current
approach automatically removes such references and finally transmits
invalidation notifications for changed objects.

Resource deletion occurs in a transaction. Currently it can leave orphaned
objects in the database. I will implement a persistent garbage collection
in the scope of another Bugzilla.

Cheers
/Eike

Chris Lenz schrieb:
> Import Export Button patch:
> Would it be possible to implement the delete function for the cdo
> resources? Can I do it myself, where have I to look for??
> Thanx Chris
>
> Eike Stepper schrieb:
>> Chris,
>>
>> If you think that import and export buttons in the CDO Explorer are a
>> good idea, please feel free to open an enhancement request.
>>
>> Cheers
>> /Eike
>>
>>
>> Chris Lenz schrieb:
>>> Hi eike,
>>>
>>> now I'am playing really a while with cdo and it is still cool.
>>>
>>> But I have one problem:
>>>
>>> I build a CDOHelper:
>>> It can load a Resource from xmi file and save it to CDO.
>>> But the otherway around is a bit tricky:
>>> It always creates only something like the following:
>>>
>>> <?xml version="1.0" encoding="ASCII"?>
>>> <organisation:Organisation xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>> name="test">
>>> <roles href="cdo://2#2"/>
>>> <roles href="cdo://2#3"/>
>>> <roles href="cdo://2#4"/>
>>> <roles href="cdo://2#5"/>
>>> <roles href="cdo://2#6"/>
>>> <users href="cdo://2#7"/>
>>> <users href="cdo://2#8"/>
>>> <users href="cdo://2#9"/>
>>> <processes href="cdo://2#10"/>
>>> <processes href="cdo://2#11"/>
>>> <processes href="cdo://2#12"/>
>>> </organisation:Organisation>
>>>
>>>
>>> Thats the code?
>>>
>>> public void saveToFile(Organisation org, String string) {
>>> try {
>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>
>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>> .put("organisation", new XMIResourceFactoryImpl());
>>> resourceSet.getPackageRegistry().put("organisation",
>>> OrganisationPackage.eINSTANCE);
>>> URI fileURI = URI.createFileURI(new File(string)
>>> .getAbsolutePath());
>>> Resource poResource = resourceSet.createResource(fileURI);
>>> poResource.getContents().add(org);
>>>
>>> poResource.save(new HashMap());
>>> } catch (Exception e) {
>>> // TODO Auto-generated catch block
>>> e.printStackTrace();
>>> }
>>>
>>> }
>>>
>

Re: CDO Resources [message #48954 is a reply to message #48780]

Thu, 07 September 2006 04:32

Eclipse User

Eike Stepper schrieb:
> Chris,
>
> I'm currently working on this bugzilla:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=156162
> I can't open the import/export icons in your patch.
> Can you please attach them directly to this newsgroup thread?
>
> Cheers
> /Eike
>
>
> Chris Lenz schrieb:
>> Import Export Button patch:
>> Would it be possible to implement the delete function for the cdo
>> resources? Can I do it myself, where have I to look for??
>> Thanx Chris
i think you have solved this, was my patch useful

-> I like writing patches, currently I write a lot fo paches for ocl. :-)

Re: CDO Resources [message #49385 is a reply to message #48867]

Fri, 08 September 2006 05:22

Eclipse User

Hi Eike,
Thanx for that great work ;-)
Chris

Eike Stepper schrieb:
> Chris,
>
> The CVS HEAD version addresses both enhancements, import/export and delete.
> You can alternatively download zips from
>
>
> http://emft.eclipse.org/technology/emft/downloads/downloads- viewer.php?proj=cdo&s=1.0.0/N200609061442/
>
>
> I'd appreciate if you could verify that the new features satisfy your
> needs.
> There is a remaining issue with CDOEditors that still have resources
> already
> deleted by other sessions, but I will fix that in another Bugzilla.
>
> Btw. resource deletions have been rather complicated to implement because
> objects in other resources can be affected by this operation. The current
> approach automatically removes such references and finally transmits
> invalidation notifications for changed objects.
>
> Resource deletion occurs in a transaction. Currently it can leave orphaned
> objects in the database. I will implement a persistent garbage collection
> in the scope of another Bugzilla.
>
> Cheers
> /Eike
>
>
> Chris Lenz schrieb:
>> Import Export Button patch:
>> Would it be possible to implement the delete function for the cdo
>> resources? Can I do it myself, where have I to look for??
>> Thanx Chris
>>
>> Eike Stepper schrieb:
>>> Chris,
>>>
>>> If you think that import and export buttons in the CDO Explorer are a
>>> good idea, please feel free to open an enhancement request.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Chris Lenz schrieb:
>>>> Hi eike,
>>>>
>>>> now I'am playing really a while with cdo and it is still cool.
>>>>
>>>> But I have one problem:
>>>>
>>>> I build a CDOHelper:
>>>> It can load a Resource from xmi file and save it to CDO.
>>>> But the otherway around is a bit tricky:
>>>> It always creates only something like the following:
>>>>
>>>> <?xml version="1.0" encoding="ASCII"?>
>>>> <organisation:Organisation xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>> name="test">
>>>> <roles href="cdo://2#2"/>
>>>> <roles href="cdo://2#3"/>
>>>> <roles href="cdo://2#4"/>
>>>> <roles href="cdo://2#5"/>
>>>> <roles href="cdo://2#6"/>
>>>> <users href="cdo://2#7"/>
>>>> <users href="cdo://2#8"/>
>>>> <users href="cdo://2#9"/>
>>>> <processes href="cdo://2#10"/>
>>>> <processes href="cdo://2#11"/>
>>>> <processes href="cdo://2#12"/>
>>>> </organisation:Organisation>
>>>>
>>>>
>>>> Thats the code?
>>>>
>>>> public void saveToFile(Organisation org, String string) {
>>>> try {
>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>
>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>> resourceSet.getPackageRegistry().put("organisation",
>>>> OrganisationPackage.eINSTANCE);
>>>> URI fileURI = URI.createFileURI(new File(string)
>>>> .getAbsolutePath());
>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>> poResource.getContents().add(org);
>>>> poResource.save(new HashMap());
>>>> } catch (Exception e) {
>>>> // TODO Auto-generated catch block
>>>> e.printStackTrace();
>>>> }
>>>>
>>>> }
>>>>
>>

Re: CDO Resources [message #585518 is a reply to message #45286]

Fri, 18 August 2006 09:49

Eclipse User

Chris,

What is the exact URI you want to save to (does it end in ".organisation")?

Is this executed against the latest CVS sources?
There is a recent change in how eResource() works for CDOPersistable
objects.
With your info below I recognize that there might be issues with
re-attached objects.
Currently an object always returns the CDOResource it was initially
attached to.
Please open a Bugzilla for this.

The latest CVS sources contain a number of bug fixes (we have
integration tests now).
Please try if the problem persists with that version.

Did you try to copy the objects from a CDOResource to the XMIResource?
There are newsgroup threads discussing that.

If all does not help, could you send me a zip with the projects so that
I can play around with them?

Cheers
/Eike

Chris Lenz schrieb:
> Hi eike,
>
> now I'am playing really a while with cdo and it is still cool.
>
> But I have one problem:
>
> I build a CDOHelper:
> It can load a Resource from xmi file and save it to CDO.
> But the otherway around is a bit tricky:
> It always creates only something like the following:
>
> <?xml version="1.0" encoding="ASCII"?>
> <organisation:Organisation xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
> name="test">
> <roles href="cdo://2#2"/>
> <roles href="cdo://2#3"/>
> <roles href="cdo://2#4"/>
> <roles href="cdo://2#5"/>
> <roles href="cdo://2#6"/>
> <users href="cdo://2#7"/>
> <users href="cdo://2#8"/>
> <users href="cdo://2#9"/>
> <processes href="cdo://2#10"/>
> <processes href="cdo://2#11"/>
> <processes href="cdo://2#12"/>
> </organisation:Organisation>
>
>
> Thats the code?
>
> public void saveToFile(Organisation org, String string) {
> try {
> ResourceSet resourceSet = new ResourceSetImpl();
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
> .put("organisation", new XMIResourceFactoryImpl());
> resourceSet.getPackageRegistry().put("organisation",
> OrganisationPackage.eINSTANCE);
> URI fileURI = URI.createFileURI(new File(string)
> .getAbsolutePath());
> Resource poResource = resourceSet.createResource(fileURI);
> poResource.getContents().add(org);
>
> poResource.save(new HashMap());
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
>

Re: CDO Resources [message #585597 is a reply to message #45286]

Fri, 18 August 2006 15:02

Eclipse User

Chris,

If you think that import and export buttons in the CDO Explorer are a
good idea, please feel free to open an enhancement request.

Cheers
/Eike

Chris Lenz schrieb:
> Hi eike,
>
> now I'am playing really a while with cdo and it is still cool.
>
> But I have one problem:
>
> I build a CDOHelper:
> It can load a Resource from xmi file and save it to CDO.
> But the otherway around is a bit tricky:
> It always creates only something like the following:
>
> <?xml version="1.0" encoding="ASCII"?>
> <organisation:Organisation xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
> name="test">
> <roles href="cdo://2#2"/>
> <roles href="cdo://2#3"/>
> <roles href="cdo://2#4"/>
> <roles href="cdo://2#5"/>
> <roles href="cdo://2#6"/>
> <users href="cdo://2#7"/>
> <users href="cdo://2#8"/>
> <users href="cdo://2#9"/>
> <processes href="cdo://2#10"/>
> <processes href="cdo://2#11"/>
> <processes href="cdo://2#12"/>
> </organisation:Organisation>
>
>
> Thats the code?
>
> public void saveToFile(Organisation org, String string) {
> try {
> ResourceSet resourceSet = new ResourceSetImpl();
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
> .put("organisation", new XMIResourceFactoryImpl());
> resourceSet.getPackageRegistry().put("organisation",
> OrganisationPackage.eINSTANCE);
> URI fileURI = URI.createFileURI(new File(string)
> .getAbsolutePath());
> Resource poResource = resourceSet.createResource(fileURI);
> poResource.getContents().add(org);
>
> poResource.save(new HashMap());
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
>

Re: CDO Resources [message #585604 is a reply to message #45286]

Fri, 18 August 2006 15:11

Eclipse User

Chris,

I think I know what happened to your exported objects. CDO generally
loads objects on demand (even contained ones). Only the root objects are
loaded together with the resource. That's why your root object is
properly serialized to XMI. The contained objects (roles, users,
processes) had not been loaded when you attached the root object to a
different resource. The proxy URIs still apply to the CDO resource but
that is no longer the container of the root. So they're not loaded
anymore and don't get resolved.

I really suggest that you EcoreUtil.copy() the CDO resource and attach
the copy to the XMI resource.

Cheers
/Eike

Chris Lenz schrieb:
> Hi eike,
>
> now I'am playing really a while with cdo and it is still cool.
>
> But I have one problem:
>
> I build a CDOHelper:
> It can load a Resource from xmi file and save it to CDO.
> But the otherway around is a bit tricky:
> It always creates only something like the following:
>
> <?xml version="1.0" encoding="ASCII"?>
> <organisation:Organisation xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
> name="test">
> <roles href="cdo://2#2"/>
> <roles href="cdo://2#3"/>
> <roles href="cdo://2#4"/>
> <roles href="cdo://2#5"/>
> <roles href="cdo://2#6"/>
> <users href="cdo://2#7"/>
> <users href="cdo://2#8"/>
> <users href="cdo://2#9"/>
> <processes href="cdo://2#10"/>
> <processes href="cdo://2#11"/>
> <processes href="cdo://2#12"/>
> </organisation:Organisation>
>
>
> Thats the code?
>
> public void saveToFile(Organisation org, String string) {
> try {
> ResourceSet resourceSet = new ResourceSetImpl();
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
> .put("organisation", new XMIResourceFactoryImpl());
> resourceSet.getPackageRegistry().put("organisation",
> OrganisationPackage.eINSTANCE);
> URI fileURI = URI.createFileURI(new File(string)
> .getAbsolutePath());
> Resource poResource = resourceSet.createResource(fileURI);
> poResource.getContents().add(org);
>
> poResource.save(new HashMap());
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
>

Re: CDO Resources [message #585637 is a reply to message #45483]

Mon, 21 August 2006 06:05

Eclipse User

Re: CDO Resources [message #585654 is a reply to message #45542]

Mon, 21 August 2006 08:44

Eclipse User

Chris,

I've opened Bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
The main outcome is that you have to use something like

protected void preLoadResource(CDOResource cdoResource)
{
for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
it.hasNext();)
{
CDOPersistable persistable = (CDOPersistable) it.next();
persistable.cdoLoad();
}
}

before you try to copy the resource with EcoreUtil.

I have to admit that I'm not completely sure about the influence of
resolveProxies during the copy process.
It seems that it does not automatically lead to loading CDOPersistables
that are proxies.
Ed: Could you explain a bit?

Maybe CDO could override an EObject method so that resolving a proxy
would also load it.
At the moment cdoLoad is only called on explicit access to persistent
features.

Cheers
/Eike

Chris Lenz schrieb:
> I tried this:
> Organisation org =
> help.loadFromRepository("cdo:///squam/test/sampleorg");
> Organisation obj = (Organisation)EcoreUtil.copy(org);
> help.saveToFile(obj,"c:\\test.organisation");
>
> That does not work??
> Chris
> Eike Stepper schrieb:
>
>> Chris,
>>
>> I think I know what happened to your exported objects. CDO generally
>> loads objects on demand (even contained ones). Only the root objects are
>> loaded together with the resource. That's why your root object is
>> properly serialized to XMI. The contained objects (roles, users,
>> processes) had not been loaded when you attached the root object to a
>> different resource. The proxy URIs still apply to the CDO resource but
>> that is no longer the container of the root. So they're not loaded
>> anymore and don't get resolved.
>>
>> I really suggest that you EcoreUtil.copy() the CDO resource and attach
>> the copy to the XMI resource.
>>
>> Cheers
>> /Eike
>>
>>
>> Chris Lenz schrieb:
>>
>>> Hi eike,
>>>
>>> now I'am playing really a while with cdo and it is still cool.
>>>
>>> But I have one problem:
>>>
>>> I build a CDOHelper:
>>> It can load a Resource from xmi file and save it to CDO.
>>> But the otherway around is a bit tricky:
>>> It always creates only something like the following:
>>>
>>> <?xml version="1.0" encoding="ASCII"?>
>>> <organisation:Organisation xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>> name="test">
>>> <roles href="cdo://2#2"/>
>>> <roles href="cdo://2#3"/>
>>> <roles href="cdo://2#4"/>
>>> <roles href="cdo://2#5"/>
>>> <roles href="cdo://2#6"/>
>>> <users href="cdo://2#7"/>
>>> <users href="cdo://2#8"/>
>>> <users href="cdo://2#9"/>
>>> <processes href="cdo://2#10"/>
>>> <processes href="cdo://2#11"/>
>>> <processes href="cdo://2#12"/>
>>> </organisation:Organisation>
>>>
>>>
>>> Thats the code?
>>>
>>> public void saveToFile(Organisation org, String string) {
>>> try {
>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>
>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>> .put("organisation", new XMIResourceFactoryImpl());
>>> resourceSet.getPackageRegistry().put("organisation",
>>> OrganisationPackage.eINSTANCE);
>>> URI fileURI = URI.createFileURI(new File(string)
>>> .getAbsolutePath());
>>> Resource poResource = resourceSet.createResource(fileURI);
>>> poResource.getContents().add(org);
>>>
>>> poResource.save(new HashMap());
>>> } catch (Exception e) {
>>> // TODO Auto-generated catch block
>>> e.printStackTrace();
>>> }
>>>
>>> }
>>>
>>>

Re: CDO Resources [message #585669 is a reply to message #45573]

Mon, 21 August 2006 08:45

Eclipse User

Ed,

I forgot to add you to the cc in the previous posting.
There's a question for you ;-)

Cheers
/Eike

Eike Stepper schrieb:
> Chris,
>
> I've opened Bugzilla
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
> The main outcome is that you have to use something like
>
> protected void preLoadResource(CDOResource cdoResource)
> {
> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
> it.hasNext();)
> {
> CDOPersistable persistable = (CDOPersistable) it.next();
> persistable.cdoLoad();
> }
> }
>
> before you try to copy the resource with EcoreUtil.
>
> I have to admit that I'm not completely sure about the influence of
> resolveProxies during the copy process.
> It seems that it does not automatically lead to loading
> CDOPersistables that are proxies.
> Ed: Could you explain a bit?
>
> Maybe CDO could override an EObject method so that resolving a proxy
> would also load it.
> At the moment cdoLoad is only called on explicit access to persistent
> features.
>
> Cheers
> /Eike
>
>
> Chris Lenz schrieb:
>> I tried this:
>> Organisation org =
>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>
>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>> help.saveToFile(obj,"c:\\test.organisation");
>>
>> That does not work??
>> Chris
>> Eike Stepper schrieb:
>>
>>> Chris,
>>>
>>> I think I know what happened to your exported objects. CDO generally
>>> loads objects on demand (even contained ones). Only the root objects
>>> are
>>> loaded together with the resource. That's why your root object is
>>> properly serialized to XMI. The contained objects (roles, users,
>>> processes) had not been loaded when you attached the root object to a
>>> different resource. The proxy URIs still apply to the CDO resource but
>>> that is no longer the container of the root. So they're not loaded
>>> anymore and don't get resolved.
>>>
>>> I really suggest that you EcoreUtil.copy() the CDO resource and attach
>>> the copy to the XMI resource.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Chris Lenz schrieb:
>>>
>>>> Hi eike,
>>>>
>>>> now I'am playing really a while with cdo and it is still cool.
>>>>
>>>> But I have one problem:
>>>>
>>>> I build a CDOHelper:
>>>> It can load a Resource from xmi file and save it to CDO.
>>>> But the otherway around is a bit tricky:
>>>> It always creates only something like the following:
>>>>
>>>> <?xml version="1.0" encoding="ASCII"?>
>>>> <organisation:Organisation xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>> name="test">
>>>> <roles href="cdo://2#2"/>
>>>> <roles href="cdo://2#3"/>
>>>> <roles href="cdo://2#4"/>
>>>> <roles href="cdo://2#5"/>
>>>> <roles href="cdo://2#6"/>
>>>> <users href="cdo://2#7"/>
>>>> <users href="cdo://2#8"/>
>>>> <users href="cdo://2#9"/>
>>>> <processes href="cdo://2#10"/>
>>>> <processes href="cdo://2#11"/>
>>>> <processes href="cdo://2#12"/>
>>>> </organisation:Organisation>
>>>>
>>>>
>>>> Thats the code?
>>>>
>>>> public void saveToFile(Organisation org, String string) {
>>>> try {
>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>
>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>> resourceSet.getPackageRegistry().put("organisation",
>>>> OrganisationPackage.eINSTANCE);
>>>> URI fileURI = URI.createFileURI(new File(string)
>>>> .getAbsolutePath());
>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>> poResource.getContents().add(org);
>>>> poResource.save(new HashMap());
>>>> } catch (Exception e) {
>>>> // TODO Auto-generated catch block
>>>> e.printStackTrace();
>>>> }
>>>>
>>>> }
>>>>

Re: CDO Resources [message #585682 is a reply to message #45604]

Mon, 21 August 2006 08:59

Eclipse User

Eike,

By default, EcoreUtil.Copier should resolve proxies as it copies and
that should cause referenced resources to be loaded as necessary.

Eike Stepper wrote:

> Ed,
>
> I forgot to add you to the cc in the previous posting.
> There's a question for you ;-)
>
> Cheers
> /Eike
>
>
> Eike Stepper schrieb:
>
>> Chris,
>>
>> I've opened Bugzilla
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
>> The main outcome is that you have to use something like
>>
>> protected void preLoadResource(CDOResource cdoResource)
>> {
>> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
>> it.hasNext();)
>> {
>> CDOPersistable persistable = (CDOPersistable) it.next();
>> persistable.cdoLoad();
>> }
>> }
>>
>> before you try to copy the resource with EcoreUtil.
>>
>> I have to admit that I'm not completely sure about the influence of
>> resolveProxies during the copy process.
>> It seems that it does not automatically lead to loading
>> CDOPersistables that are proxies.
>> Ed: Could you explain a bit?
>>
>> Maybe CDO could override an EObject method so that resolving a proxy
>> would also load it.
>> At the moment cdoLoad is only called on explicit access to persistent
>> features.
>>
>> Cheers
>> /Eike
>>
>>
>> Chris Lenz schrieb:
>>
>>> I tried this:
>>> Organisation org =
>>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>>
>>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>>> help.saveToFile(obj,"c:\\test.organisation");
>>>
>>> That does not work??
>>> Chris
>>> Eike Stepper schrieb:
>>>
>>>
>>>> Chris,
>>>>
>>>> I think I know what happened to your exported objects. CDO generally
>>>> loads objects on demand (even contained ones). Only the root
>>>> objects are
>>>> loaded together with the resource. That's why your root object is
>>>> properly serialized to XMI. The contained objects (roles, users,
>>>> processes) had not been loaded when you attached the root object to a
>>>> different resource. The proxy URIs still apply to the CDO resource but
>>>> that is no longer the container of the root. So they're not loaded
>>>> anymore and don't get resolved.
>>>>
>>>> I really suggest that you EcoreUtil.copy() the CDO resource and attach
>>>> the copy to the XMI resource.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Chris Lenz schrieb:
>>>>
>>>>
>>>>> Hi eike,
>>>>>
>>>>> now I'am playing really a while with cdo and it is still cool.
>>>>>
>>>>> But I have one problem:
>>>>>
>>>>> I build a CDOHelper:
>>>>> It can load a Resource from xmi file and save it to CDO.
>>>>> But the otherway around is a bit tricky:
>>>>> It always creates only something like the following:
>>>>>
>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>> <organisation:Organisation xmi:version="2.0"
>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>>> name="test">
>>>>> <roles href="cdo://2#2"/>
>>>>> <roles href="cdo://2#3"/>
>>>>> <roles href="cdo://2#4"/>
>>>>> <roles href="cdo://2#5"/>
>>>>> <roles href="cdo://2#6"/>
>>>>> <users href="cdo://2#7"/>
>>>>> <users href="cdo://2#8"/>
>>>>> <users href="cdo://2#9"/>
>>>>> <processes href="cdo://2#10"/>
>>>>> <processes href="cdo://2#11"/>
>>>>> <processes href="cdo://2#12"/>
>>>>> </organisation:Organisation>
>>>>>
>>>>>
>>>>> Thats the code?
>>>>>
>>>>> public void saveToFile(Organisation org, String string) {
>>>>> try {
>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>
>>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>>> resourceSet.getPackageRegistry().put("organisation",
>>>>> OrganisationPackage.eINSTANCE);
>>>>> URI fileURI = URI.createFileURI(new File(string)
>>>>> .getAbsolutePath());
>>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>>> poResource.getContents().add(org);
>>>>> poResource.save(new HashMap());
>>>>> } catch (Exception e) {
>>>>> // TODO Auto-generated catch block
>>>>> e.printStackTrace();
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>

Re: CDO Resources [message #585701 is a reply to message #45631]

Mon, 21 August 2006 09:12

Eclipse User

Ed Merks schrieb:
> Eike,
>
> By default, EcoreUtil.Copier should resolve proxies as it copies and
> that should cause referenced resources to be loaded as necessary.
In this case it is only one resource.
CDO uses proxy URIs for contained objects, too.
I assume that resolving such proxies doesn't do anything, because the
resource is already loaded from a ResourceSet perspective.

Thx
/Eike

>
>
> Eike Stepper wrote:
>
>> Ed,
>>
>> I forgot to add you to the cc in the previous posting.
>> There's a question for you ;-)
>>
>> Cheers
>> /Eike
>>
>>
>> Eike Stepper schrieb:
>>
>>> Chris,
>>>
>>> I've opened Bugzilla
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
>>> The main outcome is that you have to use something like
>>>
>>> protected void preLoadResource(CDOResource cdoResource)
>>> {
>>> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
>>> it.hasNext();)
>>> {
>>> CDOPersistable persistable = (CDOPersistable) it.next();
>>> persistable.cdoLoad();
>>> }
>>> }
>>>
>>> before you try to copy the resource with EcoreUtil.
>>>
>>> I have to admit that I'm not completely sure about the influence of
>>> resolveProxies during the copy process.
>>> It seems that it does not automatically lead to loading
>>> CDOPersistables that are proxies.
>>> Ed: Could you explain a bit?
>>>
>>> Maybe CDO could override an EObject method so that resolving a proxy
>>> would also load it.
>>> At the moment cdoLoad is only called on explicit access to
>>> persistent features.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Chris Lenz schrieb:
>>>
>>>> I tried this:
>>>> Organisation org =
>>>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>>>
>>>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>>>> help.saveToFile(obj,"c:\\test.organisation");
>>>>
>>>> That does not work??
>>>> Chris
>>>> Eike Stepper schrieb:
>>>>
>>>>
>>>>> Chris,
>>>>>
>>>>> I think I know what happened to your exported objects. CDO generally
>>>>> loads objects on demand (even contained ones). Only the root
>>>>> objects are
>>>>> loaded together with the resource. That's why your root object is
>>>>> properly serialized to XMI. The contained objects (roles, users,
>>>>> processes) had not been loaded when you attached the root object to a
>>>>> different resource. The proxy URIs still apply to the CDO resource
>>>>> but
>>>>> that is no longer the container of the root. So they're not loaded
>>>>> anymore and don't get resolved.
>>>>>
>>>>> I really suggest that you EcoreUtil.copy() the CDO resource and
>>>>> attach
>>>>> the copy to the XMI resource.
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>>
>>>>> Chris Lenz schrieb:
>>>>>
>>>>>> Hi eike,
>>>>>>
>>>>>> now I'am playing really a while with cdo and it is still cool.
>>>>>>
>>>>>> But I have one problem:
>>>>>>
>>>>>> I build a CDOHelper:
>>>>>> It can load a Resource from xmi file and save it to CDO.
>>>>>> But the otherway around is a bit tricky:
>>>>>> It always creates only something like the following:
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <organisation:Organisation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>>>> name="test">
>>>>>> <roles href="cdo://2#2"/>
>>>>>> <roles href="cdo://2#3"/>
>>>>>> <roles href="cdo://2#4"/>
>>>>>> <roles href="cdo://2#5"/>
>>>>>> <roles href="cdo://2#6"/>
>>>>>> <users href="cdo://2#7"/>
>>>>>> <users href="cdo://2#8"/>
>>>>>> <users href="cdo://2#9"/>
>>>>>> <processes href="cdo://2#10"/>
>>>>>> <processes href="cdo://2#11"/>
>>>>>> <processes href="cdo://2#12"/>
>>>>>> </organisation:Organisation>
>>>>>>
>>>>>>
>>>>>> Thats the code?
>>>>>>
>>>>>> public void saveToFile(Organisation org, String string) {
>>>>>> try {
>>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>>
>>>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>>>> resourceSet.getPackageRegistry().put("organisation",
>>>>>> OrganisationPackage.eINSTANCE);
>>>>>> URI fileURI = URI.createFileURI(new File(string)
>>>>>> .getAbsolutePath());
>>>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>>>> poResource.getContents().add(org);
>>>>>> poResource.save(new HashMap());
>>>>>> } catch (Exception e) {
>>>>>> // TODO Auto-generated catch block
>>>>>> e.printStackTrace();
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>

Re: CDO Resources [message #585716 is a reply to message #45573]

Mon, 21 August 2006 09:15

Eclipse User

Chris,

The solution I outlined below will work, but is unefficient for large
resources.
It loads the resource object by object, each causing a signal to and
from the server.
If you want you can open an enhancement request asking for optimized
"Preloading Support".

Cheers
/Eike

Eike Stepper schrieb:
> Chris,
>
> I've opened Bugzilla
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
> The main outcome is that you have to use something like
>
> protected void preLoadResource(CDOResource cdoResource)
> {
> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
> it.hasNext();)
> {
> CDOPersistable persistable = (CDOPersistable) it.next();
> persistable.cdoLoad();
> }
> }
>
> before you try to copy the resource with EcoreUtil.
>
> I have to admit that I'm not completely sure about the influence of
> resolveProxies during the copy process.
> It seems that it does not automatically lead to loading
> CDOPersistables that are proxies.
> Ed: Could you explain a bit?
>
> Maybe CDO could override an EObject method so that resolving a proxy
> would also load it.
> At the moment cdoLoad is only called on explicit access to persistent
> features.
>
> Cheers
> /Eike
>
>
> Chris Lenz schrieb:
>> I tried this:
>> Organisation org =
>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>
>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>> help.saveToFile(obj,"c:\\test.organisation");
>>
>> That does not work??
>> Chris
>> Eike Stepper schrieb:
>>
>>> Chris,
>>>
>>> I think I know what happened to your exported objects. CDO generally
>>> loads objects on demand (even contained ones). Only the root objects
>>> are
>>> loaded together with the resource. That's why your root object is
>>> properly serialized to XMI. The contained objects (roles, users,
>>> processes) had not been loaded when you attached the root object to a
>>> different resource. The proxy URIs still apply to the CDO resource but
>>> that is no longer the container of the root. So they're not loaded
>>> anymore and don't get resolved.
>>>
>>> I really suggest that you EcoreUtil.copy() the CDO resource and attach
>>> the copy to the XMI resource.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Chris Lenz schrieb:
>>>
>>>> Hi eike,
>>>>
>>>> now I'am playing really a while with cdo and it is still cool.
>>>>
>>>> But I have one problem:
>>>>
>>>> I build a CDOHelper:
>>>> It can load a Resource from xmi file and save it to CDO.
>>>> But the otherway around is a bit tricky:
>>>> It always creates only something like the following:
>>>>
>>>> <?xml version="1.0" encoding="ASCII"?>
>>>> <organisation:Organisation xmi:version="2.0"
>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>> name="test">
>>>> <roles href="cdo://2#2"/>
>>>> <roles href="cdo://2#3"/>
>>>> <roles href="cdo://2#4"/>
>>>> <roles href="cdo://2#5"/>
>>>> <roles href="cdo://2#6"/>
>>>> <users href="cdo://2#7"/>
>>>> <users href="cdo://2#8"/>
>>>> <users href="cdo://2#9"/>
>>>> <processes href="cdo://2#10"/>
>>>> <processes href="cdo://2#11"/>
>>>> <processes href="cdo://2#12"/>
>>>> </organisation:Organisation>
>>>>
>>>>
>>>> Thats the code?
>>>>
>>>> public void saveToFile(Organisation org, String string) {
>>>> try {
>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>
>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>> resourceSet.getPackageRegistry().put("organisation",
>>>> OrganisationPackage.eINSTANCE);
>>>> URI fileURI = URI.createFileURI(new File(string)
>>>> .getAbsolutePath());
>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>> poResource.getContents().add(org);
>>>> poResource.save(new HashMap());
>>>> } catch (Exception e) {
>>>> // TODO Auto-generated catch block
>>>> e.printStackTrace();
>>>> }
>>>>
>>>> }
>>>>

Re: CDO Resources [message #585736 is a reply to message #45661]

Mon, 21 August 2006 12:58

Eclipse User

This is a multi-part message in MIME format.
--------------080402090308060800080703
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Eike,

Whenever a proxy is resolved, if the result is different from the
original object, it will replace the original, as in this EcoreEList method:

protected EObject resolve(int index, EObject eObject)
{
EObject resolved = resolveProxy(eObject);
if (resolved != eObject)
{
Object oldObject = data[index];
assign(index, validate(index, resolved));
didSet(index, resolved, oldObject);

So the code doesn't care whether it's in the same resource or not...

Eike Stepper wrote:

>
> Ed Merks schrieb:
>
>> Eike,
>>
>> By default, EcoreUtil.Copier should resolve proxies as it copies and
>> that should cause referenced resources to be loaded as necessary.
>
> In this case it is only one resource.
> CDO uses proxy URIs for contained objects, too.
> I assume that resolving such proxies doesn't do anything, because the
> resource is already loaded from a ResourceSet perspective.
>
> Thx
> /Eike
>
>
>>
>>
>> Eike Stepper wrote:
>>
>>> Ed,
>>>
>>> I forgot to add you to the cc in the previous posting.
>>> There's a question for you ;-)
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Eike Stepper schrieb:
>>>
>>>> Chris,
>>>>
>>>> I've opened Bugzilla
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
>>>> The main outcome is that you have to use something like
>>>>
>>>> protected void preLoadResource(CDOResource cdoResource)
>>>> {
>>>> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
>>>> it.hasNext();)
>>>> {
>>>> CDOPersistable persistable = (CDOPersistable) it.next();
>>>> persistable.cdoLoad();
>>>> }
>>>> }
>>>>
>>>> before you try to copy the resource with EcoreUtil.
>>>>
>>>> I have to admit that I'm not completely sure about the influence of
>>>> resolveProxies during the copy process.
>>>> It seems that it does not automatically lead to loading
>>>> CDOPersistables that are proxies.
>>>> Ed: Could you explain a bit?
>>>>
>>>> Maybe CDO could override an EObject method so that resolving a
>>>> proxy would also load it.
>>>> At the moment cdoLoad is only called on explicit access to
>>>> persistent features.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Chris Lenz schrieb:
>>>>
>>>>> I tried this:
>>>>> Organisation org =
>>>>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>>>>
>>>>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>>>>> help.saveToFile(obj,"c:\\test.organisation");
>>>>>
>>>>> That does not work??
>>>>> Chris
>>>>> Eike Stepper schrieb:
>>>>>
>>>>>
>>>>>> Chris,
>>>>>>
>>>>>> I think I know what happened to your exported objects. CDO generally
>>>>>> loads objects on demand (even contained ones). Only the root
>>>>>> objects are
>>>>>> loaded together with the resource. That's why your root object is
>>>>>> properly serialized to XMI. The contained objects (roles, users,
>>>>>> processes) had not been loaded when you attached the root object
>>>>>> to a
>>>>>> different resource. The proxy URIs still apply to the CDO
>>>>>> resource but
>>>>>> that is no longer the container of the root. So they're not loaded
>>>>>> anymore and don't get resolved.
>>>>>>
>>>>>> I really suggest that you EcoreUtil.copy() the CDO resource and
>>>>>> attach
>>>>>> the copy to the XMI resource.
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>>
>>>>>> Chris Lenz schrieb:
>>>>>>
>>>>>>
>>>>>>> Hi eike,
>>>>>>>
>>>>>>> now I'am playing really a while with cdo and it is still cool.
>>>>>>>
>>>>>>> But I have one problem:
>>>>>>>
>>>>>>> I build a CDOHelper:
>>>>>>> It can load a Resource from xmi file and save it to CDO.
>>>>>>> But the otherway around is a bit tricky:
>>>>>>> It always creates only something like the following:
>>>>>>>
>>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>>> <organisation:Organisation xmi:version="2.0"
>>>>>>> xmlns:xmi="http://www.omg.org/XMI"
>>>>>>> xmlns:organisation="organisation"
>>>>>>> name="test">
>>>>>>> <roles href="cdo://2#2"/>
>>>>>>> <roles href="cdo://2#3"/>
>>>>>>> <roles href="cdo://2#4"/>
>>>>>>> <roles href="cdo://2#5"/>
>>>>>>> <roles href="cdo://2#6"/>
>>>>>>> <users href="cdo://2#7"/>
>>>>>>> <users href="cdo://2#8"/>
>>>>>>> <users href="cdo://2#9"/>
>>>>>>> <processes href="cdo://2#10"/>
>>>>>>> <processes href="cdo://2#11"/>
>>>>>>> <processes href="cdo://2#12"/>
>>>>>>> </organisation:Organisation>
>>>>>>>
>>>>>>>
>>>>>>> Thats the code?
>>>>>>>
>>>>>>> public void saveToFile(Organisation org, String string) {
>>>>>>> try {
>>>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>>>
>>>>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>>>>> resourceSet.getPackageRegistry().put("organisation",
>>>>>>> OrganisationPackage.eINSTANCE);
>>>>>>> URI fileURI = URI.createFileURI(new File(string)
>>>>>>> .getAbsolutePath());
>>>>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>>>>> poResource.getContents().add(org);
>>>>>>> poResource.save(new HashMap());
>>>>>>> } catch (Exception e) {
>>>>>>> // TODO Auto-generated catch block
>>>>>>> e.printStackTrace();
>>>>>>> }
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>
>>>>>>

--------------080402090308060800080703
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike, 
 
Whenever a proxy is resolved, if the result is different from the
original object, it will replace the original, as in this EcoreEList
method: 
<blockquote>

Re: CDO Resources [message #585878 is a reply to message #45691]

Tue, 22 August 2006 05:21

Eclipse User

Re: CDO Resources [message #585890 is a reply to message #45996]

Tue, 22 August 2006 05:31

Eclipse User

Re: CDO Resources [message #585921 is a reply to message #45996]

Tue, 22 August 2006 07:06

Eclipse User

Chris,

If you send me a patch, I can review and apply it.

Cheers
/Eike

Chris Lenz schrieb:
> We should use getAllProperContents instead of getAllContents
>
> Now I am implementing the load and save action into the CDOExplorer.
> Can I add this to repository, and how can I do this?
> Chris
> Eike Stepper schrieb:
>> Chris,
>>
>> The solution I outlined below will work, but is unefficient for large
>> resources.
>> It loads the resource object by object, each causing a signal to and
>> from the server.
>> If you want you can open an enhancement request asking for optimized
>> "Preloading Support".
>>
>> Cheers
>> /Eike
>>
>>
>> Eike Stepper schrieb:
>>> Chris,
>>>
>>> I've opened Bugzilla
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=154522 for it.
>>> The main outcome is that you have to use something like
>>>
>>> protected void preLoadResource(CDOResource cdoResource)
>>> {
>>> for (Iterator it = EcoreUtil.getAllContents(cdoResource, true);
>>> it.hasNext();)
>>> {
>>> CDOPersistable persistable = (CDOPersistable) it.next();
>>> persistable.cdoLoad();
>>> }
>>> }
>>>
>>> before you try to copy the resource with EcoreUtil.
>>>
>>> I have to admit that I'm not completely sure about the influence of
>>> resolveProxies during the copy process.
>>> It seems that it does not automatically lead to loading
>>> CDOPersistables that are proxies.
>>> Ed: Could you explain a bit?
>>>
>>> Maybe CDO could override an EObject method so that resolving a proxy
>>> would also load it.
>>> At the moment cdoLoad is only called on explicit access to persistent
>>> features.
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Chris Lenz schrieb:
>>>> I tried this:
>>>> Organisation org =
>>>> help.loadFromRepository("cdo:///squam/test/sampleorg");
>>>>
>>>> Organisation obj = (Organisation)EcoreUtil.copy(org);
>>>> help.saveToFile(obj,"c:\\test.organisation");
>>>>
>>>> That does not work??
>>>> Chris
>>>> Eike Stepper schrieb:
>>>>
>>>>> Chris,
>>>>>
>>>>> I think I know what happened to your exported objects. CDO generally
>>>>> loads objects on demand (even contained ones). Only the root objects
>>>>> are
>>>>> loaded together with the resource. That's why your root object is
>>>>> properly serialized to XMI. The contained objects (roles, users,
>>>>> processes) had not been loaded when you attached the root object to a
>>>>> different resource. The proxy URIs still apply to the CDO resource but
>>>>> that is no longer the container of the root. So they're not loaded
>>>>> anymore and don't get resolved.
>>>>>
>>>>> I really suggest that you EcoreUtil.copy() the CDO resource and attach
>>>>> the copy to the XMI resource.
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>>
>>>>> Chris Lenz schrieb:
>>>>>
>>>>>> Hi eike,
>>>>>>
>>>>>> now I'am playing really a while with cdo and it is still cool.
>>>>>>
>>>>>> But I have one problem:
>>>>>>
>>>>>> I build a CDOHelper:
>>>>>> It can load a Resource from xmi file and save it to CDO.
>>>>>> But the otherway around is a bit tricky:
>>>>>> It always creates only something like the following:
>>>>>>
>>>>>> <?xml version="1.0" encoding="ASCII"?>
>>>>>> <organisation:Organisation xmi:version="2.0"
>>>>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>>>>> name="test">
>>>>>> <roles href="cdo://2#2"/>
>>>>>> <roles href="cdo://2#3"/>
>>>>>> <roles href="cdo://2#4"/>
>>>>>> <roles href="cdo://2#5"/>
>>>>>> <roles href="cdo://2#6"/>
>>>>>> <users href="cdo://2#7"/>
>>>>>> <users href="cdo://2#8"/>
>>>>>> <users href="cdo://2#9"/>
>>>>>> <processes href="cdo://2#10"/>
>>>>>> <processes href="cdo://2#11"/>
>>>>>> <processes href="cdo://2#12"/>
>>>>>> </organisation:Organisation>
>>>>>>
>>>>>>
>>>>>> Thats the code?
>>>>>>
>>>>>> public void saveToFile(Organisation org, String string) {
>>>>>> try {
>>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>>
>>>>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>>>>> .put("organisation", new XMIResourceFactoryImpl());
>>>>>> resourceSet.getPackageRegistry().put("organisation",
>>>>>> OrganisationPackage.eINSTANCE);
>>>>>> URI fileURI = URI.createFileURI(new File(string)
>>>>>> .getAbsolutePath());
>>>>>> Resource poResource = resourceSet.createResource(fileURI);
>>>>>> poResource.getContents().add(org);
>>>>>> poResource.save(new HashMap());
>>>>>> } catch (Exception e) {
>>>>>> // TODO Auto-generated catch block
>>>>>> e.printStackTrace();
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>

Re: CDO Resources [message #585938 is a reply to message #46026]

Tue, 22 August 2006 07:14

Eclipse User

Chris Lenz schrieb:
> preLoadResource loads only toplevel elements

My proposal for a preLoadResource loads all objects contained in that resource.
I verified this with a test case.
If your resource does not get fully loaded, please explain a bit more.

> myworkaround:
> protected static void preLoadResource(CDOResource cdoResource) {
> int i = 1;
> int old = 0;
> while (old < i) {
> old = i;
> i = 0;
> for (Iterator it = EcoreUtil
> .getAllProperContents(cdoResource, true); it.hasNext();) {
> CDOPersistable persistable = (CDOPersistable) it.next();
> persistable.cdoLoad();
> i++;
> }
> }
> }

This seems a bit of a brute force ;-)
The effort can be O(n*n) where n is the number of objects in the resource.

Cheers
/Eike

Re: CDO Resources [message #585950 is a reply to message #46117]

Tue, 22 August 2006 09:22

Eclipse User

Re: CDO Resources [message #586045 is a reply to message #46147]

Tue, 22 August 2006 11:39

Eclipse User

Chris Lenz schrieb:
> Ok in my case it loads not objects contained in that resource, I try to
> explain.
>
> If the resource looks like the following:
> toplevelElement
> -subelement
> -subsubelement
> -subsubsubelement
> -subelement
> -subsubelement
> -subsubsubelement
>
> in the first iteration it loads the toplevelelement and all subelements.
>
> in the next iteration it loads on level more, it loads also the
> subsubelements.
> and so on.
>
> I hope that's understandable!

I already understood that your method works like that ;-)
But I asked you to explain, what exactly did not work with my method.
As I said, it works for me (and performs better than yours).
Can you provide a zip with the source code that you used to test my method?

Cheers
/Eike

Re: CDO Resources [message #586055 is a reply to message #46293]

Wed, 23 August 2006 04:15

Eclipse User

Re: CDO Resources [message #586084 is a reply to message #46323]

Wed, 23 August 2006 05:54

Eclipse User

Chris,

Please don't spend any more effort for constructing an example!
I could reproduce your issue in /org.eclipse.emf.cdo.tests/src/org/eclipse/emf/cdo/tests/mod el1/SerializationTest.java
Look for testExportThreeLevels().

The issue is caused because EObject.eContents() does not call cdoLoad().
I've fixed this in CDOPersistentImpl:

/**
* @ADDED
*/
@Override
public EList eContents()
{
cdoLoad();
return super.eContents();
}

The changes are committed to CVS.
Can you please verify that it works for you?

Cheers
/Eike

Chris Lenz schrieb:
> This your model have more than two levels.
>
> My application is very complex, but I try to create some easier.
> Chris
> Eike Stepper schrieb:
>> Chris Lenz schrieb:
>>> Ok in my case it loads not objects contained in that resource, I try to
>>> explain.
>>>
>>> If the resource looks like the following:
>>> toplevelElement
>>> -subelement
>>> -subsubelement
>>> -subsubsubelement
>>> -subelement
>>> -subsubelement
>>> -subsubsubelement
>>>
>>> in the first iteration it loads the toplevelelement and all subelements.
>>>
>>> in the next iteration it loads on level more, it loads also the
>>> subsubelements.
>>> and so on.
>>>
>>> I hope that's understandable!
>> I already understood that your method works like that ;-)
>> But I asked you to explain, what exactly did not work with my method.
>> As I said, it works for me (and performs better than yours).
>> Can you provide a zip with the source code that you used to test my method?
>>
>> Cheers
>> /Eike
>>

Re: CDO Resources [message #590151 is a reply to message #45455]

Mon, 04 September 2006 12:48

Eclipse User

Re: CDO Resources [message #590278 is a reply to message #48451]

Tue, 05 September 2006 12:23

Eclipse User

Chris,

I'm currently working on this bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=156162
I can't open the import/export icons in your patch.
Can you please attach them directly to this newsgroup thread?

Cheers
/Eike

Chris Lenz schrieb:
> Import Export Button patch:
> Would it be possible to implement the delete function for the cdo
> resources? Can I do it myself, where have I to look for??
> Thanx Chris

Re: CDO Resources [message #590318 is a reply to message #48451]

Wed, 06 September 2006 15:20

Eclipse User

Chris,

The CVS HEAD version addresses both enhancements, import/export and delete.
You can alternatively download zips from

http://emft.eclipse.org/technology/emft/downloads/downloads- viewer.php?proj=cdo&s=1.0.0/N200609061442/

I'd appreciate if you could verify that the new features satisfy your needs.
There is a remaining issue with CDOEditors that still have resources already
deleted by other sessions, but I will fix that in another Bugzilla.

Btw. resource deletions have been rather complicated to implement because
objects in other resources can be affected by this operation. The current
approach automatically removes such references and finally transmits
invalidation notifications for changed objects.

Resource deletion occurs in a transaction. Currently it can leave orphaned
objects in the database. I will implement a persistent garbage collection
in the scope of another Bugzilla.

Cheers
/Eike

Chris Lenz schrieb:
> Import Export Button patch:
> Would it be possible to implement the delete function for the cdo
> resources? Can I do it myself, where have I to look for??
> Thanx Chris
>
> Eike Stepper schrieb:
>> Chris,
>>
>> If you think that import and export buttons in the CDO Explorer are a
>> good idea, please feel free to open an enhancement request.
>>
>> Cheers
>> /Eike
>>
>>
>> Chris Lenz schrieb:
>>> Hi eike,
>>>
>>> now I'am playing really a while with cdo and it is still cool.
>>>
>>> But I have one problem:
>>>
>>> I build a CDOHelper:
>>> It can load a Resource from xmi file and save it to CDO.
>>> But the otherway around is a bit tricky:
>>> It always creates only something like the following:
>>>
>>> <?xml version="1.0" encoding="ASCII"?>
>>> <organisation:Organisation xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI" xmlns:organisation="organisation"
>>> name="test">
>>> <roles href="cdo://2#2"/>
>>> <roles href="cdo://2#3"/>
>>> <roles href="cdo://2#4"/>
>>> <roles href="cdo://2#5"/>
>>> <roles href="cdo://2#6"/>
>>> <users href="cdo://2#7"/>
>>> <users href="cdo://2#8"/>
>>> <users href="cdo://2#9"/>
>>> <processes href="cdo://2#10"/>
>>> <processes href="cdo://2#11"/>
>>> <processes href="cdo://2#12"/>
>>> </organisation:Organisation>
>>>
>>>
>>> Thats the code?
>>>
>>> public void saveToFile(Organisation org, String string) {
>>> try {
>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>
>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>> .put("organisation", new XMIResourceFactoryImpl());
>>> resourceSet.getPackageRegistry().put("organisation",
>>> OrganisationPackage.eINSTANCE);
>>> URI fileURI = URI.createFileURI(new File(string)
>>> .getAbsolutePath());
>>> Resource poResource = resourceSet.createResource(fileURI);
>>> poResource.getContents().add(org);
>>>
>>> poResource.save(new HashMap());
>>> } catch (Exception e) {
>>> // TODO Auto-generated catch block
>>> e.printStackTrace();
>>> }
>>>
>>> }
>>>
>

Re: CDO Resources [message #590363 is a reply to message #48780]

Thu, 07 September 2006 04:32

Eclipse User

Re: CDO Resources [message #590561 is a reply to message #48867]

Fri, 08 September 2006 05:22

Eclipse User

Previous Topic:	java.lang.NoClassDefFoundError: org/elver/store/StoreException
Next Topic:	java.lang.NoClassDefFoundError: org/elver/store/StoreException

Goto Forum:

-=] Back to Top [=-

Current Time: Thu May 01 10:41:16 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter