Home » Modeling » EMF » [EMF] [CDO] ResourceSet, EPackage registry question
|
| Re: [EMF] [CDO] ResourceSet, EPackage registry question [message #1222403 is a reply to message #1222042] |
Fri, 20 December 2013 10:26   |
 Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hi,
OK no response sofar, let me try to rephrase my horrible initial question:
Scenario 1:
Load a XMI Resource with a ResourceSet, first register the EPackage in
the registry of the ResourceSet.
uri = new URI("file://project/model.xmi")
set = ResourceSetImpl()
set.getPackageRegistry().put(nsURI, p);
set.getResource(uri);
The returned EObject's have EClass instances from the EPackage
registered in the ResourceSet.
Scenario 2:
Load a CDO Resource with a Resourceset, first register the Epackage in
the registry of the ResourceSet
uri = new URI("cdo.net4j.tcp://host:port/repo_source/model")
set = ResourceSetImpl()
set.getPackageRegistry().put(nsURI, p);
set.getResource(uri);
The returned EObjects have EClass instances from a new EPackage instance
(Produced I guess from the transfer CDO Package Registry on the server,
*I assume*).
On the 2nd scenario this breaks the Edapt code has it expects the eCLass
from an EObject to conform the EPackage instance registered in the
ResourceSet (Which is apparently not used). I am looking for a way to
fix Edapt to work with CDO Resources with a different EPackage instance.
TIA Christophe
On 19-12-13 15:11, Christophe Bouhier wrote:
> Hi,
>
> Is the following statement true?
>
> In case of an XMIResource, A ResourceSet loaded with EPackage A with
> EClass B in it's EPackage registy will load resources and set a loaded
> EObject's eClass to the EClass instance (of B) as defined by EPackage A?
>
> The reason I ask is that Edapt makes use of this assumption and won't
> work if resources are not loaded with a certain instance of an EPackage
> (And it's EClass's etc..).
>
> With CDO, when I load a resource it's not going to use the EPackage
> instance which was set in the resource set, but the EPackage instance
> provided by CDO it seems?
>
>
> Rgds Christophe
|
|
|
| Re: [EMF] [CDO] ResourceSet, EPackage registry question [message #1222415 is a reply to message #1222403] |
Fri, 20 December 2013 10:51 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Looking at the code:
In EObjectInputStream for an EMF Resource, get the EPackage from the
resourceset.
protected EPackageData readEPackage() throws IOException
{
int id = readCompressedInt();
if (internalEPackageDataList.size() <= id)
{
EPackageData ePackageData = new EPackageData();
String nsURI = readSegmentedString();
URI uri = readURI();
if (resourceSet != null)
{
ePackageData.ePackage =
resourceSet.getPackageRegistry().getEPackage(nsURI);
if (ePackageData.ePackage == null)
{
ePackageData.ePackage =
(EPackage)resourceSet.getEObject(uri, true);
}
}
I am looking for the equivalent in CDO, but with dynamic loading
concept, I guess this can not be similar, correct?
Thanks Christophe
On 20-12-13 11:26, Christophe Bouhier wrote:
> Hi,
>
> OK no response sofar, let me try to rephrase my horrible initial question:
>
> Scenario 1:
>
> Load a XMI Resource with a ResourceSet, first register the EPackage in
> the registry of the ResourceSet.
>
>
> uri = new URI("file://project/model.xmi")
> set = ResourceSetImpl()
> set.getPackageRegistry().put(nsURI, p);
> set.getResource(uri);
>
>
>
> The returned EObject's have EClass instances from the EPackage
> registered in the ResourceSet.
>
>
> Scenario 2:
>
> Load a CDO Resource with a Resourceset, first register the Epackage in
> the registry of the ResourceSet
>
> uri = new URI("cdo.net4j.tcp://host:port/repo_source/model")
> set = ResourceSetImpl()
> set.getPackageRegistry().put(nsURI, p);
> set.getResource(uri);
>
>
> The returned EObjects have EClass instances from a new EPackage instance
> (Produced I guess from the transfer CDO Package Registry on the server,
> *I assume*).
>
>
> On the 2nd scenario this breaks the Edapt code has it expects the eCLass
> from an EObject to conform the EPackage instance registered in the
> ResourceSet (Which is apparently not used). I am looking for a way to
> fix Edapt to work with CDO Resources with a different EPackage instance.
>
> TIA Christophe
>
>
>
> On 19-12-13 15:11, Christophe Bouhier wrote:
>> Hi,
>>
>> Is the following statement true?
>>
>> In case of an XMIResource, A ResourceSet loaded with EPackage A with
>> EClass B in it's EPackage registy will load resources and set a loaded
>> EObject's eClass to the EClass instance (of B) as defined by EPackage A?
>>
>> The reason I ask is that Edapt makes use of this assumption and won't
>> work if resources are not loaded with a certain instance of an EPackage
>> (And it's EClass's etc..).
>>
>> With CDO, when I load a resource it's not going to use the EPackage
>> instance which was set in the resource set, but the EPackage instance
>> provided by CDO it seems?
>>
>>
>> Rgds Christophe
>
|
|
|
| Re: [EMF] [CDO] ResourceSet, EPackage registry question [message #1222458 is a reply to message #1222403] |
Fri, 20 December 2013 13:25 |
|
Hi Christoph,
When there are already instances of that EClass in the repository then the related EPackage is also in the repo and when
a client session connects it knows about that. Later when that EPackage is needed (i.e. package descriptor resolves)
it's either wired from the global registry or loaded from the repo.
More comments below...
Am 20.12.2013 11:26, schrieb Christophe Bouhier:
> Hi,
>
> OK no response sofar, let me try to rephrase my horrible initial question:
>
> Scenario 1:
>
> Load a XMI Resource with a ResourceSet, first register the EPackage in the registry of the ResourceSet.
>
>
> uri = new URI("file://project/model.xmi")
> set = ResourceSetImpl()
> set.getPackageRegistry().put(nsURI, p);
> set.getResource(uri);
>
>
>
> The returned EObject's have EClass instances from the EPackage registered in the ResourceSet.
>
>
> Scenario 2:
>
> Load a CDO Resource with a Resourceset, first register the Epackage in the registry of the ResourceSet
>
> uri = new URI("cdo.net4j.tcp://host:port/repo_source/model")
> set = ResourceSetImpl()
> set.getPackageRegistry().put(nsURI, p);
I think this can be dangerous if p is a dynamic (i.e. not a singleton) EPackage.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> set.getResource(uri);
>
>
> The returned EObjects have EClass instances from a new EPackage instance (Produced I guess from the transfer CDO
> Package Registry on the server, *I assume*).
>
>
> On the 2nd scenario this breaks the Edapt code has it expects the eCLass from an EObject to conform the EPackage
> instance registered in the ResourceSet (Which is apparently not used). I am looking for a way to fix Edapt to work
> with CDO Resources with a different EPackage instance.
>
> TIA Christophe
>
>
>
> On 19-12-13 15:11, Christophe Bouhier wrote:
>> Hi,
>>
>> Is the following statement true?
>>
>> In case of an XMIResource, A ResourceSet loaded with EPackage A with
>> EClass B in it's EPackage registy will load resources and set a loaded
>> EObject's eClass to the EClass instance (of B) as defined by EPackage A?
>>
>> The reason I ask is that Edapt makes use of this assumption and won't
>> work if resources are not loaded with a certain instance of an EPackage
>> (And it's EClass's etc..).
>>
>> With CDO, when I load a resource it's not going to use the EPackage
>> instance which was set in the resource set, but the EPackage instance
>> provided by CDO it seems?
>>
>>
>> Rgds Christophe
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [EMF] [CDO] ResourceSet, EPackage registry question [message #1223481 is a reply to message #1222458] |
Mon, 23 December 2013 14:23 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
On 20-12-13 14:25, Eike Stepper wrote:
> Hi Christoph,
>
> When there are already instances of that EClass in the repository then
> the related EPackage is also in the repo and when a client session
> connects it knows about that. Later when that EPackage is needed (i.e.
> package descriptor resolves) it's either wired from the global registry
> or loaded from the repo.
>
Thanks Eike. Can you please explain how it gets in the global registry?
Is it cached there, after the first time load from the Repository?
Thanks.
> More comments below...
>
>
>
> Am 20.12.2013 11:26, schrieb Christophe Bouhier:
>> Hi,
>>
>> OK no response sofar, let me try to rephrase my horrible initial
>> question:
>>
>> Scenario 1:
>>
>> Load a XMI Resource with a ResourceSet, first register the EPackage in
>> the registry of the ResourceSet.
>>
>>
>> uri = new URI("file://project/model.xmi")
>> set = ResourceSetImpl()
>> set.getPackageRegistry().put(nsURI, p);
>> set.getResource(uri);
>>
>>
>>
>> The returned EObject's have EClass instances from the EPackage
>> registered in the ResourceSet.
>>
>>
>> Scenario 2:
>>
>> Load a CDO Resource with a Resourceset, first register the Epackage in
>> the registry of the ResourceSet
>>
>> uri = new URI("cdo.net4j.tcp://host:port/repo_source/model")
>> set = ResourceSetImpl()
>> set.getPackageRegistry().put(nsURI, p);
> I think this can be dangerous if p is a dynamic (i.e. not a singleton)
> EPackage.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>> set.getResource(uri);
>>
>>
>> The returned EObjects have EClass instances from a new EPackage
>> instance (Produced I guess from the transfer CDO Package Registry on
>> the server, *I assume*).
>>
>>
>> On the 2nd scenario this breaks the Edapt code has it expects the
>> eCLass from an EObject to conform the EPackage instance registered in
>> the ResourceSet (Which is apparently not used). I am looking for a way
>> to fix Edapt to work with CDO Resources with a different EPackage
>> instance.
>>
>> TIA Christophe
>>
>>
>>
>> On 19-12-13 15:11, Christophe Bouhier wrote:
>>> Hi,
>>>
>>> Is the following statement true?
>>>
>>> In case of an XMIResource, A ResourceSet loaded with EPackage A with
>>> EClass B in it's EPackage registy will load resources and set a loaded
>>> EObject's eClass to the EClass instance (of B) as defined by
>>> EPackage A?
>>>
>>> The reason I ask is that Edapt makes use of this assumption and won't
>>> work if resources are not loaded with a certain instance of an EPackage
>>> (And it's EClass's etc..).
>>>
>>> With CDO, when I load a resource it's not going to use the EPackage
>>> instance which was set in the resource set, but the EPackage instance
>>> provided by CDO it seems?
>>>
>>>
>>> Rgds Christophe
>>
>
|
|
|
| Re: [EMF] [CDO] ResourceSet, EPackage registry question [message #1226982 is a reply to message #1223481] |
Fri, 03 January 2014 08:05 |
|
Am 23.12.2013 15:23, schrieb Christophe Bouhier:
> On 20-12-13 14:25, Eike Stepper wrote:
>> Hi Christoph,
>>
>> When there are already instances of that EClass in the repository then
>> the related EPackage is also in the repo and when a client session
>> connects it knows about that. Later when that EPackage is needed (i.e.
>> package descriptor resolves) it's either wired from the global registry
>> or loaded from the repo.
>>
> Thanks Eike. Can you please explain how it gets in the global registry?
> Is it cached there, after the first time load from the Repository?
Generated packages get into the global registry via their plugin.xml markup. CDO is not involved there. But CDO looks up
nsURIs there. Look at org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.load(PackageLoader, boolean).
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Thanks.
>
>
>
>> More comments below...
>>
>>
>>
>> Am 20.12.2013 11:26, schrieb Christophe Bouhier:
>>> Hi,
>>>
>>> OK no response sofar, let me try to rephrase my horrible initial
>>> question:
>>>
>>> Scenario 1:
>>>
>>> Load a XMI Resource with a ResourceSet, first register the EPackage in
>>> the registry of the ResourceSet.
>>>
>>>
>>> uri = new URI("file://project/model.xmi")
>>> set = ResourceSetImpl()
>>> set.getPackageRegistry().put(nsURI, p);
>>> set.getResource(uri);
>>>
>>>
>>>
>>> The returned EObject's have EClass instances from the EPackage
>>> registered in the ResourceSet.
>>>
>>>
>>> Scenario 2:
>>>
>>> Load a CDO Resource with a Resourceset, first register the Epackage in
>>> the registry of the ResourceSet
>>>
>>> uri = new URI("cdo.net4j.tcp://host:port/repo_source/model")
>>> set = ResourceSetImpl()
>>> set.getPackageRegistry().put(nsURI, p);
>> I think this can be dangerous if p is a dynamic (i.e. not a singleton)
>> EPackage.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>> set.getResource(uri);
>>>
>>>
>>> The returned EObjects have EClass instances from a new EPackage
>>> instance (Produced I guess from the transfer CDO Package Registry on
>>> the server, *I assume*).
>>>
>>>
>>> On the 2nd scenario this breaks the Edapt code has it expects the
>>> eCLass from an EObject to conform the EPackage instance registered in
>>> the ResourceSet (Which is apparently not used). I am looking for a way
>>> to fix Edapt to work with CDO Resources with a different EPackage
>>> instance.
>>>
>>> TIA Christophe
>>>
>>>
>>>
>>> On 19-12-13 15:11, Christophe Bouhier wrote:
>>>> Hi,
>>>>
>>>> Is the following statement true?
>>>>
>>>> In case of an XMIResource, A ResourceSet loaded with EPackage A with
>>>> EClass B in it's EPackage registy will load resources and set a loaded
>>>> EObject's eClass to the EClass instance (of B) as defined by
>>>> EPackage A?
>>>>
>>>> The reason I ask is that Edapt makes use of this assumption and won't
>>>> work if resources are not loaded with a certain instance of an EPackage
>>>> (And it's EClass's etc..).
>>>>
>>>> With CDO, when I load a resource it's not going to use the EPackage
>>>> instance which was set in the resource set, but the EPackage instance
>>>> provided by CDO it seems?
>>>>
>>>>
>>>> Rgds Christophe
>>>
>>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [EMF] [CDO] ResourceSet, EPackage registry question [message #1226983 is a reply to message #1226982] |
Fri, 03 January 2014 08:07 |
|
And you can create a CDOPackageRegistryPopulator to lazily mirror any EPackage.Registry content into a CDOPackageRegistry.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 03.01.2014 09:05, schrieb Eike Stepper:
> Am 23.12.2013 15:23, schrieb Christophe Bouhier:
>> On 20-12-13 14:25, Eike Stepper wrote:
>>> Hi Christoph,
>>>
>>> When there are already instances of that EClass in the repository then
>>> the related EPackage is also in the repo and when a client session
>>> connects it knows about that. Later when that EPackage is needed (i.e.
>>> package descriptor resolves) it's either wired from the global registry
>>> or loaded from the repo.
>>>
>> Thanks Eike. Can you please explain how it gets in the global registry?
>> Is it cached there, after the first time load from the Repository?
> Generated packages get into the global registry via their plugin.xml markup. CDO is not involved there. But CDO looks
> up nsURIs there. Look at org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.load(PackageLoader, boolean).
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>
>> Thanks.
>>
>>
>>
>>> More comments below...
>>>
>>>
>>>
>>> Am 20.12.2013 11:26, schrieb Christophe Bouhier:
>>>> Hi,
>>>>
>>>> OK no response sofar, let me try to rephrase my horrible initial
>>>> question:
>>>>
>>>> Scenario 1:
>>>>
>>>> Load a XMI Resource with a ResourceSet, first register the EPackage in
>>>> the registry of the ResourceSet.
>>>>
>>>>
>>>> uri = new URI("file://project/model.xmi")
>>>> set = ResourceSetImpl()
>>>> set.getPackageRegistry().put(nsURI, p);
>>>> set.getResource(uri);
>>>>
>>>>
>>>>
>>>> The returned EObject's have EClass instances from the EPackage
>>>> registered in the ResourceSet.
>>>>
>>>>
>>>> Scenario 2:
>>>>
>>>> Load a CDO Resource with a Resourceset, first register the Epackage in
>>>> the registry of the ResourceSet
>>>>
>>>> uri = new URI("cdo.net4j.tcp://host:port/repo_source/model")
>>>> set = ResourceSetImpl()
>>>> set.getPackageRegistry().put(nsURI, p);
>>> I think this can be dangerous if p is a dynamic (i.e. not a singleton)
>>> EPackage.
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>> set.getResource(uri);
>>>>
>>>>
>>>> The returned EObjects have EClass instances from a new EPackage
>>>> instance (Produced I guess from the transfer CDO Package Registry on
>>>> the server, *I assume*).
>>>>
>>>>
>>>> On the 2nd scenario this breaks the Edapt code has it expects the
>>>> eCLass from an EObject to conform the EPackage instance registered in
>>>> the ResourceSet (Which is apparently not used). I am looking for a way
>>>> to fix Edapt to work with CDO Resources with a different EPackage
>>>> instance.
>>>>
>>>> TIA Christophe
>>>>
>>>>
>>>>
>>>> On 19-12-13 15:11, Christophe Bouhier wrote:
>>>>> Hi,
>>>>>
>>>>> Is the following statement true?
>>>>>
>>>>> In case of an XMIResource, A ResourceSet loaded with EPackage A with
>>>>> EClass B in it's EPackage registy will load resources and set a loaded
>>>>> EObject's eClass to the EClass instance (of B) as defined by
>>>>> EPackage A?
>>>>>
>>>>> The reason I ask is that Edapt makes use of this assumption and won't
>>>>> work if resources are not loaded with a certain instance of an EPackage
>>>>> (And it's EClass's etc..).
>>>>>
>>>>> With CDO, when I load a resource it's not going to use the EPackage
>>>>> instance which was set in the resource set, but the EPackage instance
>>>>> provided by CDO it seems?
>>>>>
>>>>>
>>>>> Rgds Christophe
>>>>
>>>
>>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Sat Sep 14 07:45:23 GMT 2024
Powered by FUDForum. Page generated in 0.04618 seconds |
] 
Search
Help
Register
Login
Home
