Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Commit data and its meta model => unresolved proxy error
[CDO] Commit data and its meta model => unresolved proxy error [message #1024065] Mon, 25 March 2013 19:05 Go to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
Hi there,

I try to store both in a CDO repository: data and its meta model (ecore). Unfortunately, I get unresolved proxy errors. Storing just one resource is no problem (also if both are indepenedent from each other). However, if the stored meta model is used for creating the data (dynamic), it doesn't work. I debugged into the code, but still cannot find the real problem.

I think I am using the most recent version of CDO (4.2.x)

I created the following minimal example:

CDONet4jSession session = /* ... */;

// load ecore meta model
Resource resourceMetamodel = new ResourceSetImpl().getResource(
		URI.createFileURI(/* ... */), true);

CDOTransaction cdoTransaction = session.openTransaction();
try {
	
	// save meta model in CDO resource
	CDOResource cdoResourceMetamodel = cdoTransaction.createResource("/meta");
	List<EObject> objMeta = new ArrayList<EObject>(resourceMetamodel.getContents());
	for (EObject obj : objMeta)
		cdoResourceMetamodel.getContents().add(obj);

	EPackage packageMetamodel = (EPackage) cdoResourceMetamodel.getContents().get(0);
			
	// register meta model
	session.getPackageRegistry().putEPackage(packageMetamodel);

	// create some data (create root object)
	EFactory modelFactory = packageMetamodel.getEFactoryInstance();
	EObject rootObject = modelFactory.create((EClass) packageMetamodel.getEClassifier("AClass"));

	// save data in CDO resource
	CDOResource cdoResourceData = cdoTransaction.createResource("/data");
	cdoResourceData.getContents().add(rootObject);

	cdoTransaction.commit();

} catch (CommitException e) {
	e.printStackTrace();
} finally {
	cdoTransaction.close();
}


You can use the following meta model (ecore). I use a simple containment reference inside. Without reference, I have no problem as well.

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="APackage" nsURI="http://anURI" nsPrefix="prefix">
  <eClassifiers xsi:type="ecore:EClass" name="AClass">
    <eStructuralFeatures xsi:type="ecore:EReference" name="Test" upperBound="-1" eType="#//AClass"
        containment="true"/>
  </eClassifiers>
</ecore:EPackage>


And some details about the error:

Caused by: java.lang.IllegalStateException: Unresolvable proxy: http://anURI/L4
	at org.eclipse.emf.cdo.common.model.EMFUtil.safeResolve(EMFUtil.java:570)
	at org.eclipse.emf.cdo.common.model.EMFUtil.safeResolveAll(EMFUtil.java:600)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:152)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:96)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)
	at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:86)
	at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:92)
	at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
	at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
	at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:65)


Thanks in advance!

[Updated on: Mon, 25 March 2013 19:09]

Report message to a moderator

Re: [CDO] Commit data and its meta model => unresolved proxy error [message #1030795 is a reply to message #1024065] Sun, 31 March 2013 19:37 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
Unfortunately, I haven't found a solution to my problem yet. Because I really need this feature, i.e. storing the meta model within my repository, I continued research. Accidentally, I found the following piece of information (http://wiki.eclipse.org/CDO/Server_Configuration_Reference):

Quote:
Property supportingEcore

Specifies whether the repository will support the storage of instances of the Ecore (meta meta) model or not.

With the advent of the legacy mode (support for models not generated as CDO native models) in CDO 3.0 you can store instances of any model in CDO repositories. Whether these models have been generated for CDO or not only influences their characteristics (scalability, performance, etc.). As a consequence you can also store instances of the Ecore (meta meta) model in CDO Repositories. Since Ecore has always been registered in all package registries the legacy mode would lead to the creation of mapped tables in many types of stores, even if you never planned to store instances of Ecore.


If I understand this part correctly, commiting the meta model should be no problem at all. Of course, I tried setting the configuration for "supportingEcore". However, I get the same error Sad

Please provide some information, no matter if this completely solves my problem or not. I don't even know if further investigation is meaningful. Do you think that this should work? Is this a bug or not? Does it work on other systems/configurations? I appreciate any help. Thanks!
Re: [CDO] Commit data and ist meta model =&gt; unresolved proxy error [message #1031004 is a reply to message #1024065] Mon, 01 April 2013 03:52 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6681
Registered: July 2009
Senior Member
Hi Kirsten,

Sorry for the late reply, I've just returned from the EclipseCon in Boston.

CDO stores meta models in a separate area of the repository that relates to the package registry and not the instance
data. And it does that automatically. So the following code works:

public void testDynamicPackageLoaded() throws Exception
{
EPackage model1 = loadModel("model1.ecore");

CDOSession session = openSession();
session.getPackageRegistry().putEPackage(model1);

EFactory modelFactory = model1.getEFactoryInstance(); // Must happen AFTER putEPackage!!!
EObject object = modelFactory.create((EClass)model1.getEClassifier("Company"));

CDOTransaction transaction = session.openTransaction();
CDOResource resource = transaction.createResource("/data");
resource.getContents().add(object);

transaction.commit();
}

You can also store EPackages in the instance area but then you can't use them at the same time to create instances
(because the EPackage could change at any time thereafter).

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Am 25.03.2013 20:05, schrieb Kirsten M. Z.:
> Hi there,
>
> I try to store both in a CDO repository: data and its meta model (ecore). Unfortunately, I get unresolved proxy
> errors. Storing just one resource is no problem (also if both are indepenedent from each other). However, if the
> stored meta model is used for creating the data (dynamic), it doesn't work. I debugged into the code, but still cannot
> find the real problem.
>
> I think I am using the most recent version of CDO (4.2.x)
>
> I created the following minimal example:
>
> CDONet4jSession session = /* ... */;
>
> // load ecore meta model
> Resource resourceMetamodel = new ResourceSetImpl().getResource(
> URI.createFileURI(/* ... */), true);
>
> CDOTransaction cdoTransaction = session.openTransaction();
> try {
>
> // save meta model in CDO resource
> CDOResource cdoResourceMetamodel = cdoTransaction.createResource("/meta");
> List<EObject> objMeta = new ArrayList<EObject>(resourceMetamodel.getContents());
> for (EObject obj : objMeta)
> cdoResourceMetamodel.getContents().add(obj);
>
> EPackage packageMetamodel = (EPackage) cdoResourceMetamodel.getContents().get(0);
>
> // register meta model
> session.getPackageRegistry().putEPackage(packageMetamodel);
>
> // create some data (create root object)
> EFactory modelFactory = packageMetamodel.getEFactoryInstance();
> EObject rootObject = modelFactory.create((EClass) packageMetamodel.getEClassifier("AClass"));
>
> // save data in CDO resource
> CDOResource cdoResourceData = cdoTransaction.createResource("/data");
> cdoResourceData.getContents().add(rootObject);
>
> cdoTransaction.commit();
>
> } catch (CommitException e) {
> e.printStackTrace();
> } finally {
> cdoTransaction.close();
> }
>
> You can use the following meta model (ecore). I use a simple containment reference inside. Without reference, I have
> no Problem as well.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="APackage" nsURI="http://anURI" nsPrefix="prefix">
> <eClassifiers xsi:type="ecore:EClass" name="AClass">
> <eStructuralFeatures xsi:type="ecore:EReference" name="Test" upperBound="-1" eType="#//AClass"
> containment="true"/>
> </eClassifiers>
> </ecore:EPackage>
>
> And some details about the error:
>
> Caused by: java.lang.IllegalStateException: Unresolvable proxy: http://anURI/L4
> at org.eclipse.emf.cdo.common.model.EMFUtil.safeResolve(EMFUtil.java:570)
> at org.eclipse.emf.cdo.common.model.EMFUtil.safeResolveAll(EMFUtil.java:600)
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:152)
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:96)
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)
> at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:86)
> at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:92)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
> at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
> at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:65)
>
> Thanks in advance!


Re: [CDO] Commit data and ist meta model =&gt; unresolved proxy error [message #1031567 is a reply to message #1031004] Mon, 01 April 2013 23:47 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
Thanks for your reply. I expected that you are in Boston Smile Just wanted to push the topic in order to emphasize its importance for me.

I expected that CDO does some magic stuff storing the meta data in a special repository part. For several reasons and many twists and turns, I could not find any evidence. After your post I investigated the database again (in depth), and I found the data, I guess. Is it stored in some BLOB field in table CDO_PACKAGE_UNIT? How is it serialized? Can it be referenced? Such details are important for me in order to understand why errors occur and which workarounds I need.

Yes, I need workarounds, I guess. And this is also why I am unhappy with the way the meta model is stored. It is no problem, that it is read-only. However, I need to reference the meta model. I try to use Edapt and want to save a history within the repository. This history references to a meta model, which again is used for some data stored in the same repository.

Naively, but with a queasy feeling, I expected that the following code works:

EPackage packageMetamodelCDO = EMFUtil.getTopLevelPackage(cdoTransaction.getResource("data").getContents().get(0).eClass().getEPackage());


This way I can access the meta model (i.e. a package) of the data ("data") stored in the repository.

However, if the history (also stored in the repository as "history") is linked to this package, I get errors after the original ecore file is deleted. These errors started to confuse me. No chance without insider knowledge! The error messages include the original ecore filename! Therefore, I started to wonder if the meta model is really stored in the repository.

Now, I think that I revealed the secret: the original filename (URI) is stored in the repository?!? Calling
packageMetamodelCDO.eResource()
returns a resource with that URI. And this is also why opening the history ends with an error that the meta model cannot be found, if the original file is really deleted from disk.

Can you tell me if I am right? Can you give me some advice? Which workaround is meaningful?

To sum up, what I need is to
- store data
- store the meta model (ecore, no code generation, read-only is fine)
- store some additional data which references to the meta model
Re: [CDO] Commit data and ist meta model =&amp;gt; unresolved proxy error [message #1031982 is a reply to message #1031567] Tue, 02 April 2013 12:37 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi, Kirsten,

It strikes me that what you are doing is similar to UML Profiles, which
define a dynamic Ecore model and instances thereof in a CDO repository.
The CDO integration feature of Papyrus makes use of this.

You might have a look at the test cases in the
org.eclipse.emf.cdo.tests.uml project in the CDO Git for comparison
with your case.

I make one or two comments in-line, below.

HTH,

Christian


On 2013-04-01 23:47:11 +0000, Kirsten M. Z. said:

> Thanks for your reply. I expected that you are in Boston :) Just wanted
> to push the topic in order to emphasize its importance for me.
>
> I expected that CDO does some magic stuff storing the meta data in a
> special repository part. For several reasons and many twists and turns,
> I could not find any evidence. After your post I investigated the
> database again (in depth), and I found the data, I guess. Is it stored
> in some BLOB field in table CDO_PACKAGE_UNIT? How is it serialized? Can
> it be referenced? Such details are important for me in order to
> understand why errors occur and which workarounds I need.
>
> Yes, I need workarounds, I guess. And this is also why I am unhappy
> with the way the meta model is stored. It is no problem, that it is
> read-only. However, I need to reference the meta model. I try to use
> Edapt and want to save a history within the repository. This history
> references to a meta model, which again is used for some data stored in
> the same repository.

If your Ecore model is changing over time, then I suppose you will need
to account for the fact that the schema in the CDO repository is
static. The schema generated from a package is immutable. A new
version of the package needs a distinct URI and, I think, generates an
entirely separate suite of tables in the database. Schema evolution is
still an open question ... it has been raised several times in this
forum, which a search should turn up. I don't recall off-hand whether
and how much work has been put into implementing some solution for
schema evolution.


> Naively, but with a queasy feeling, I expected that the following code works:
>
> EPackage packageMetamodelCDO =
> EMFUtil.getTopLevelPackage(cdoTransaction.getResource("data").getContents().get(0).eClass().getEPackage());
>

You should just be able to look up the namespace URI in the
ResourceSet's package registry ... Or, if necessary, in the
CDOSession's package registry.


> This way I can access the meta model (i.e. a package) of the data
> ("data") stored in the repository.
>
> However, if the history (also stored in the repository as "history") is
> linked to this package, I get errors after the original ecore file is
> deleted. These errors started to confuse me. No chance without insider
> knowledge! The error messages include the original ecore filename!
> Therefore, I started to wonder if the meta model is really stored in
> the repository.

>
> Now, I think that I revealed the secret: the original filename (URI) is
> stored in the repository?!? Calling packageMetamodelCDO.eResource()
> returns a resource with that URI. And this is also why opening the
> history ends with an error that the meta model cannot be found, if the
> original file is really deleted from disk.

EPackages in the package registry need to be contained by Resources for
referenceability, as usual. For that purpose, they typically create
for themselves a Resource with their namespace URI.


> Can you tell me if I am right? Can you give me some advice? Which
> workaround is meaningful?
>
> To sum up, what I need is to
> - store data
> - store the meta model (ecore, no code generation, read-only is fine)
> - store some additional data which references to the meta model
Re: [CDO] Commit data and ist meta model =&amp;gt; unresolved proxy error [message #1032299 is a reply to message #1031982] Tue, 02 April 2013 20:54 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
> It strikes me that what you are doing is similar to UML Profiles, which
> define a dynamic Ecore model and instances thereof in a CDO repository.
> The CDO integration feature of Papyrus makes use of this.

I use UML and UML profiles very often and I also know many details about EMF and the EMF profile for extending UML. However, I don't get the point that my use case is similar to UML profiles. Can you point/link to further information about the relationship between dynamic ecore models, UML profiles and CDO? I will have a look at the mentioned test cases, of course.

> If your Ecore model is changing over time, then I suppose you will need
> to account for the fact that the schema in the CDO repository is
> static. The schema generated from a package is immutable. A new
> version of the package needs a distinct URI and, I think, generates an
> entirely separate suite of tables in the database. Schema evolution is
> still an open question ... it has been raised several times in this
> forum, which a search should turn up. I don't recall off-hand whether
> and how much work has been put into implementing some solution for
> schema evolution.

I also checked this. If the name of the meta model and all used classes are changed, migration with Edapt is (almost) no problem. This means new tables for migrated classes etc.


know any projects or features which relates UML profiles to dynamic ecore model
Re: [CDO] Commit data and ist meta model =&amp;amp;gt; unresolved proxy error [message #1032317 is a reply to message #1032299] Tue, 02 April 2013 21:25 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi, Kirsten,

See replies in-line, below.

HTH,

Christian


On 2013-04-02 20:54:22 +0000, Kirsten M. Z. said:

>>
>> It strikes me that what you are doing is similar to UML Profiles, which
>> define a dynamic Ecore model and instances thereof in a CDO repository.
>> The CDO integration feature of Papyrus makes use of this.
>
> I use UML and UML profiles very often and I also know many details
> about EMF and the EMF profile for extending UML. However, I don't get
> the point that my use case is similar to UML profiles. Can you
> point/link to further information about the relationship between
> dynamic ecore models, UML profiles and CDO? I will have a look at the
> mentioned test cases, of course.

UML profiles (in the Eclipse UML2 implementation) use dynamic Ecore
models to describe stereotype instances. So, a UML model that has a
profile applied stores both the metamodel (Ecore model of stereotypes)
and data (stereotype instances) in the same set of resources.

Papyrus, with its CDO integration, now stores profiled UML models in
CDO repositories. This is analogous to your need to store Ecore models
and their instances in the repository. The EPackage definition of a
profile is "processed" by CDO to inject the CDOFactoryImpl into it, so
that stereotype instances are created as DynamicCDOObjectImpls instead
of the usual DynamicEObjectImpls. The EPackage definition of a profile
ends up being stored in *both* the CDO server's user data area (within
the UML Profile data) and the CDO server's package metadata area.


>> If your Ecore model is changing over time, then I suppose you will need
>> to account for the fact that the schema in the CDO repository is
>> static. The schema generated from a package is immutable. A new version
>> of the package needs a distinct URI and, I think, generates an entirely
>> separate suite of tables in the database. Schema evolution is still an
>> open question ... it has been raised several times in this forum, which
>> a search should turn up. I don't recall off-hand whether and how much
>> work has been put into implementing some solution for schema evolution.
>
> I also checked this. If the name of the meta model and all used classes
> are changed, migration with Edapt is (almost) no problem. This means
> new tables for migrated classes etc.
>
>
> know any projects or features which relates UML profiles to dynamic ecore model
Re: [CDO] Commit data and ist meta model =&amp;gt; unresolved proxy error [message #1034374 is a reply to message #1031567] Fri, 05 April 2013 11:09 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6681
Registered: July 2009
Senior Member
Am 02.04.2013 01:47, schrieb Kirsten M. Z.:
> Thanks for your reply. I expected that you are in Boston :) Just wanted to push the topic in order to emphasize its
> importance for me.
>
> I expected that CDO does some magic stuff storing the meta data in a special repository part. For several reasons and
> many twists and turns, I could not find any evidence. After your post I investigated the database again (in depth),
> and I found the data, I guess. Is it stored in some BLOB field in table CDO_PACKAGE_UNIT? How is it serialized?
That's correct. It is the result of calling org.eclipse.emf.cdo.common.model.EMFUtil.getEPackageBytes() with zipped=true.

> Can it be referenced?
Yes, CDO can handle references from EObjects (instance area) to registered EModelElements (meta model area). It treats
them as "external references".

> Such details are important for me in order to understand why errors occur and which workarounds I need.
>
> Yes, I need workarounds, I guess.
Normally not. But it depends on what exactly you want to do.

> And this is also why I am unhappy with the way the meta model is stored. It is no problem, that it is read-only.
> However, I need to reference the meta model. I try to use Edapt and want to save a history within the repository. This
> history references to a meta model, which again is used for some data stored in the same repository.
You should be able to store instances of Ecore in the instance area of a repository and there it would be mutable. To
store instances of these EClasses in that repository, too, you'd need to register a copy of these dynamic models with
the package registry of your CDOSession. Note that you cannot register two versions of an EPackage under the same nsURI!

>
> Naively, but with a queasy feeling, I expected that the following code works:
>
> EPackage packageMetamodelCDO =
> EMFUtil.getTopLevelPackage(cdoTransaction.getResource("data").getContents().get(0).eClass().getEPackage());
>
> This way I can access the meta model (i.e. a package) of the data ("data") stored in the repository.
>
> However, if the history (also stored in the repository as "history") is linked to this package, I get errors after the
> original ecore file is deleted.
Probably because you didn't register an immutable copy of the package.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


> These errors started to confuse me. No chance without insider knowledge! The error messages include the original ecore
> filename! Therefore, I started to wonder if the meta model is really stored in the repository.
>
> Now, I think that I revealed the secret: the original filename (URI) is stored in the repository?!? Calling
> packageMetamodelCDO.eResource() returns a resource with that URI. And this is also why opening the history ends with
> an error that the meta model cannot be found, if the original file is really deleted from disk.
>
> Can you tell me if I am right? Can you give me some advice? Which workaround is meaningful?
>
> To sum up, what I need is to
> - store data
> - store the meta model (ecore, no code generation, read-only is fine)
> - store some additional data which references to the meta model


Previous Topic:[CDO] CDO server hacking, where to start?
Next Topic:CDOServerImporter throws Unique index or primary key violation
Goto Forum:
  


Current Time: Tue Mar 19 04:44:26 GMT 2024

Powered by FUDForum. Page generated in 0.02692 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top