Community
Participate
Working Groups
Build Identifier: 20100204-1618 I'm using CDO 3 with hibernate store to persist my models. I've tried using the Company example it works fine, but with my metamodel it fails. My metamodel contains 3 subpackages which references each others in a cyclic way. When I start the server, and execute my class which creates elements on the cdoresource, an exception happens at transaction commit and my tables are not created on the database. When I restart the server, my packages are registered so my tables are created at this time, and if i execute the code again, it works fine. After debugging, I discovered that when an eclass references another one existing in another package, the last one is not considered as loaded yet so it's recognized by its eproxy uri.So it's not found in the map which associates Model elements to PAnnotatedEModelElement. I've tried separating my subpackages in different models it still doesn't work. Reproducible: Always Steps to Reproduce: 1.Create a metamodel with many subpackages, each of them using eclasses of the others 2.generate cdo code of the metamodel 3.launch a cdo server using an hibernate store 4.launch a class which registers all subpackages of the metamodel, and creates a cdo resource with one element 5.stop the server and relaunch it (tables of the metamodel should be created at this time) 6.reexecute the class which create the cdo resource (at this time it should work)
Created attachment 170175 [details] the exception happening when trying to create elements on the db for the first time
Created attachment 170176 [details] The metamodel
Can you please provide us with the minimum model/code required to reproduce this issue?
Created attachment 170177 [details] model code plugin
Created attachment 170178 [details] plugin containing the test class which reproduces the problem
The CDO tests already have 2 cases for circular package dependencies: org.eclipse.emf.cdo.tests.PackageRegistryTest.testCommitCircularPackages() org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_256141_Test.testBugzilla_256141() Martin, can you start investigating in HibernateStore/Teneo?
I spend several hours on this this morning. The example packages you provided have nsuri which ends with a #. This results in proxies not being resolved. This happened with me even before I got into the Teneo mapping functionality, so your bugzilla can still be very valid. Can you provide sample models without a # in the namespace? Then I can take a look at it again. See also this post on the EMF newsgroup on using # in namespace uris: http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg05768.html I wonder though how did the # end up in the namespace uri? Was this done by EMF when converting a xsd to ecore? gr. Martin
Created attachment 170511 [details] Partial patch This patch addresses the problem that the check in CDOModelUtil was using the EGenericType's own resource instead of the resource of the element that is referenced through the EGenericType. There's still a problem though: after applying this patch it occurs on the server side, for the same model element that caused trouble in the CDOModelUtil.checkCrossResourceURIs. Will investigate further, but must warn that my knowledge of advanced EMF tricks (such as seem to be used in this model) are pretty much over my head.
My suspicion is that the trouble derives from the nsURI declared for the RDFType feature in RdfsResource, via ExtendedMetaData: <eStructuralFeatures xsi:type="ecore:EReference" name="RDFtype" lowerBound="1" upperBound="-1" eType="#//RDFSClass" eOpposite="#//RDFSClass/typedResource"> <eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData"> <details key="kind" value="element"/> <details key="namespace" value="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/> </eAnnotations> </eStructuralFeatures> I don't know what it means for a model element to have a different nsURI from its owner and its owner's package, nor how do I know how EMF deals with this. Therefore I also don't know how CDO "should" deal with it. Perhaps the bug reporter can explain?
CC'ing Ed. Maybe he has deeper insights regarding the strange # (hash) character in an nsURI...
It seems likely that a # will mess up when the nsURI is used as a reference, i.e., <nsuURI>#<fragment-path>. A URI with more then one # technically isn't valid; EMF will allow that but treats the second # as part of the fragment.
I've tried after removing # from nsuri of my models, it works. The # is not due to a conversion from an xsd to an ecore, in fact i'm working on an owl ontology editor using emf api. I've to define a handler which reads the rdf format. As for the nsuris with #, they are the real uris of rdf, rdfs and owl languages. <eStructuralFeatures xsi:type="ecore:EReference" name="RDFtype" lowerBound="1" upperBound="-1" eType="#//RDFSClass" eOpposite="#//RDFSClass/typedResource"> <eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData"> <details key="kind" value="element"/> <details key="namespace" value="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/> </eAnnotations> </eStructuralFeatures> This annotation is used to test some code, I won't keep it like that. That's why i have not used it as it should be. Thank you very much for your help
Hi Chahid, To be sure, you mean that after removing the # from the uri now everything works as expected and you encounter no issues? gr. Martin
Yes Martin everything works well. My tables are created and my elements are saved on database as expected.
Ok good to hear! Then I close this issue for now. I solved a number of other issues yesterday. So it can make sense to try a new CDO build after today (I am not sure when Eike will promote/publish the next build). gr. Martin
Oeps, maybe to quick closing this one as there is a patch attached. Caspar/Eike, what to do with this patch (it is not a hibernate store patch)? Will you commit it? gr. Martin
(In reply to comment #16) > Caspar/Eike, what to do with this patch (it is not a hibernate store patch)? It *seems* the check is more robust with the patch in place. But then, as discussed, I find EGenericTypes to be somewhat obscure creatures, so perhaps someone with a better understanding of them should take a look at it. I'm reopening it and flagging it for Eike's review.
Legal note: No code from the usewr has been used.
Comment on attachment 170511 [details] Partial patch My patch committed to HEAD.
Chahid, please test the fix in your scenario and reopen this bug if it does not fully address the original problem. Resolving FIXED.
Hi Eike, I've tested the fix it works.
Thanks, Chahid and Caspar!
Thanks everybody for your help!
Available in 3.0 GA: http://download.eclipse.org/modeling/emf/cdo/updates/3.0-releases/
