Home » Modeling » EMF » [CDO] Cannot commit UML stereotype instances
| [CDO] Cannot commit UML stereotype instances [message #908757] |
Wed, 05 September 2012 20:23  |
Eclipse User |
|
|
|
Hi,
Using the Juno release of CDO, I have a problem with UML models in
"legacy mode". Basic model structures all seem to work fine. The
problem happens in dynamic EPackage definitions of UML profiles.
Using the EMF dynamic_package extension point, I can register the Ecore
package embedded within a UML profile (*.profile.uml resource) and EMF
correctly loads and registers it at run-time. In the CDO UI, I can use
the "CDO Package Registry" dialog to add this package to my session
using the "Generated…" button. However, it appears and behaves
differently than other packages:
- the icon is a ghostly grey package, not light purple (legacy) or
dark purple (native)
- the Type column shows a question mark instead of legacy/native type
- the Original column shows "UNKNOWN" instead of a legacy/native type
Dynamic EPackages from *.ecore resources in show up correctly as
DYNAMIC type with the package-on-a-page icon.
I suspect that all this is indicative of the cause of my real problem,
which is that I cannot commit instances of the EClasses in such a
dynamic package into the repository. If I create a new root object in
a resource that is an instance of one of these EClasses, representing a
stereotype application on a UML element, then attempting to commit
fails with a server-side exception (see below) that looks to me like
transmission of the dynamic package to the repository results in an
attempt to instantiate the EModelElement class, which is abstract.
Questions:
- am I doing something wrong in registering or using this dynamic package?
- is this a known problem?
- is this happening because the dynamic package is not the root of an
Ecore resource, but
rather nested within in an EAnnotation in a UML profile in a UML resource?
Thanks,
Christian
-------- 8< --------
!ENTRY org.eclipse.net4j 4 0 2012-09-05 20:16:26.560
!MESSAGE The class 'EModelElement' is not a valid classifier
!STACK 0
java.lang.IllegalArgumentException: The class 'EModelElement' is not a
valid classifier
at
org.eclipse.emf.ecore.impl.EcoreFactoryImpl.create(EcoreFactoryImpl.java:99)
at org.eclipse.emf.ecore.impl.EFactoryImpl.create(EFactoryImpl.java:260)
at
org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:885)
at
org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:922)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFactory(XMLHandler.java:2180)
...
at org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHandler.java:163)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501)
...
at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:175)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:240)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1505)
at org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFUtil.java:305)
at
org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CDOModelUtil.java:519)
at
org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.read(CDOPackageUnitImpl.java:301)
at
org.eclipse.emf.cdo.internal.common.protocol.CDODataInputImpl.readCDOPackageUnit(CDODataInputImpl.java:115)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:142)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:95)
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)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
|
|
|
| Re: [CDO] Cannot commit UML stereotype instances [message #909111 is a reply to message #908757] |
Thu, 06 September 2012 11:00  |
| Eclipse User |
|
|
|
Hi,
Following up, I see in the debugger that the problem is that the
resource sent to the server containing my dynamic EPackage is, of
course, a UML profile resource. So, its root is a UML Profile
instance. The EPackage is in an EAnnotation contained in the Profile.
When deserializng the resource, the server is trying to use a
CDOFactoryImpl to create an instance of the Profile eclass.
CDOFactoryImpl is mostly just an EFactoryImpl, and EFactoryImpl's
implementation of the create(EClass) method attempts to instantiate the
*superclass* of the requested eclass, without even first checking
whether the eclass itself has an instance class.
Why on Earth would the generic EFactoryImpl start by trying to
instantiate the superclass instead of the class that it was asked to
instantiate? In this case, it's abstract (EModelElement) and so,
naturally, fails.
In any case, I wouldn't really expect to have the UML metamodel on the
server, would I? I thought CDO didn't use EMF on the back-end. If it
does, then maybe I have my server OSGi misconfigured?
Thanks,
Christian
On 2012-09-06 00:23:18 +0000, Christian W. Damus said:
> Hi,
>
> Using the Juno release of CDO, I have a problem with UML models in
> "legacy mode". Basic model structures all seem to work fine. The
> problem happens in dynamic EPackage definitions of UML profiles.
>
> Using the EMF dynamic_package extension point, I can register the Ecore
> package embedded within a UML profile (*.profile.uml resource) and EMF
> correctly loads and registers it at run-time. In the CDO UI, I can use
> the "CDO Package Registry" dialog to add this package to my session
> using the "Generated…" button. However, it appears and behaves
> differently than other packages:
>
> - the icon is a ghostly grey package, not light purple (legacy) or
> dark purple (native)
> - the Type column shows a question mark instead of legacy/native type
> - the Original column shows "UNKNOWN" instead of a legacy/native type
>
> Dynamic EPackages from *.ecore resources in show up correctly as
> DYNAMIC type with the package-on-a-page icon.
>
> I suspect that all this is indicative of the cause of my real problem,
> which is that I cannot commit instances of the EClasses in such a
> dynamic package into the repository. If I create a new root object in
> a resource that is an instance of one of these EClasses, representing a
> stereotype application on a UML element, then attempting to commit
> fails with a server-side exception (see below) that looks to me like
> transmission of the dynamic package to the repository results in an
> attempt to instantiate the EModelElement class, which is abstract.
>
> Questions:
>
> - am I doing something wrong in registering or using this dynamic package?
> - is this a known problem?
> - is this happening because the dynamic package is not the root of an
> Ecore resource, but
> rather nested within in an EAnnotation in a UML profile in a UML resource?
>
> Thanks,
>
> Christian
>
>
> -------- 8< --------
>
> !ENTRY org.eclipse.net4j 4 0 2012-09-05 20:16:26.560
> !MESSAGE The class 'EModelElement' is not a valid classifier
> !STACK 0
> java.lang.IllegalArgumentException: The class 'EModelElement' is not a
> valid classifier
> at
> org.eclipse.emf.ecore.impl.EcoreFactoryImpl.create(EcoreFactoryImpl.java:99)
>
> at org.eclipse.emf.ecore.impl.EFactoryImpl.create(EFactoryImpl.java:260)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:885)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:922)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFactory(XMLHandler.java:2180)
>
> ...
> at org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHandler.java:163)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501)
>
> ...
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
> at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:175)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:240)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1505)
>
> at org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFUtil.java:305)
> at
> org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CDOModelUtil.java:519)
>
> at
> org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.read(CDOPackageUnitImpl.java:301)
>
> at
> org.eclipse.emf.cdo.internal.common.protocol.CDODataInputImpl.readCDOPackageUnit(CDODataInputImpl.java:115)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:142)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:95)
>
> 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)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
|
|
|
| Re: [CDO] Cannot commit UML stereotype instances [message #909132 is a reply to message #909111] |
Thu, 06 September 2012 11:36 |
| Eclipse User |
|
|
|
Hi Christian,
Sorry, I'm behind with your inital question.
Comments below...
Am 06.09.2012 17:00, schrieb Christian W. Damus:
> Hi,
>
> Following up, I see in the debugger that the problem is that the resource sent to the server containing my dynamic
> EPackage is, of course, a UML profile resource. So, its root is a UML Profile instance. The EPackage is in an
> EAnnotation contained in the Profile.
I may misunderstand but you're not expecting this dynamic EPackage, which is a child of an instance object, to end up in
CDO's package registry and be available for object creation/management, are you?
>
> When deserializng the resource, the server is trying to use a CDOFactoryImpl to create an instance of the Profile
> eclass. CDOFactoryImpl is mostly just an EFactoryImpl, and EFactoryImpl's implementation of the create(EClass) method
> attempts to instantiate the *superclass* of the requested eclass, without even first checking whether the eclass
> itself has an instance class.
>
> Why on Earth would the generic EFactoryImpl start by trying to instantiate the superclass instead of the class that it
> was asked to instantiate? In this case, it's abstract (EModelElement) and so, naturally, fails.
Maybe it's related to the fact that the EPackage/EFactory pair is not being registered in the usual EMF/CDO
infrastructure (e.g. CDOPackageRegistry of CDOSession or IRepository).
>
> In any case, I wouldn't really expect to have the UML metamodel on the server, would I?
Well usually you would expect so. But not in the normal "instance space". A repository must have access to the used
EPackages and must make them available (dynamically) to clients that don't have the original generated model at hand.
> I thought CDO didn't use EMF on the back-end.
This old article still sums up the status quo correctly: http://thegordian.blogspot.de/2009/03/emf-on-server.html
> If it does, then maybe I have my server OSGi misconfigured?
Hard to say, but I doubt it. Maybe you can write a small test case so that I can reproduce it here? Let me know if you
need start pointers regarding our test framework. If you want we could also have a teamviewer session on your box.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Thanks,
>
> Christian
>
>
> On 2012-09-06 00:23:18 +0000, Christian W. Damus said:
>
>> Hi,
>>
>> Using the Juno release of CDO, I have a problem with UML models in "legacy mode". Basic model structures all seem to
>> work fine. The problem happens in dynamic EPackage definitions of UML profiles.
>>
>> Using the EMF dynamic_package extension point, I can register the Ecore package embedded within a UML profile
>> (*.profile.uml resource) and EMF correctly loads and registers it at run-time. In the CDO UI, I can use the "CDO
>> Package Registry" dialog to add this package to my session using the "Generated…" button. However, it appears and
>> behaves differently than other packages:
>>
>> - the icon is a ghostly grey package, not light purple (legacy) or dark purple (native)
>> - the Type column shows a question mark instead of legacy/native type
>> - the Original column shows "UNKNOWN" instead of a legacy/native type
>>
>> Dynamic EPackages from *.ecore resources in show up correctly as DYNAMIC type with the package-on-a-page icon.
>>
>> I suspect that all this is indicative of the cause of my real problem, which is that I cannot commit instances of the
>> EClasses in such a dynamic package into the repository. If I create a new root object in a resource that is an
>> instance of one of these EClasses, representing a stereotype application on a UML element, then attempting to commit
>> fails with a server-side exception (see below) that looks to me like transmission of the dynamic package to the
>> repository results in an attempt to instantiate the EModelElement class, which is abstract.
>>
>> Questions:
>>
>> - am I doing something wrong in registering or using this dynamic package?
>> - is this a known problem?
>> - is this happening because the dynamic package is not the root of an Ecore resource, but
>> rather nested within in an EAnnotation in a UML profile in a UML resource?
>>
>> Thanks,
>>
>> Christian
>>
>>
>> -------- 8< --------
>>
>> !ENTRY org.eclipse.net4j 4 0 2012-09-05 20:16:26.560
>> !MESSAGE The class 'EModelElement' is not a valid classifier
>> !STACK 0
>> java.lang.IllegalArgumentException: The class 'EModelElement' is not a valid classifier
>> at org.eclipse.emf.ecore.impl.EcoreFactoryImpl.create(EcoreFactoryImpl.java:99)
>> at org.eclipse.emf.ecore.impl.EFactoryImpl.create(EFactoryImpl.java:260)
>> at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:885)
>> at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:922)
>> at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFactory(XMLHandler.java:2180)
>> ...
>> at org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHandler.java:163)
>> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501)
>> ...
>> at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
>> at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:175)
>> at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:240)
>> at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1505)
>> at org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFUtil.java:305)
>> at org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CDOModelUtil.java:519)
>> at org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.read(CDOPackageUnitImpl.java:301)
>> at org.eclipse.emf.cdo.internal.common.protocol.CDODataInputImpl.readCDOPackageUnit(CDODataInputImpl.java:115)
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:142)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:95)
>>
>> 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)
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
>
>
|
|
|
| Re: [CDO] Cannot commit UML stereotype instances [message #909146 is a reply to message #909132] |
Thu, 06 September 2012 12:00 |
| Eclipse User |
|
|
|
Thanks, Eike,
No need to apologize. You're very generous with your time in this newsgroup!
Answers in-line.
cW
On 2012-09-06 15:36:39 +0000, Eike Stepper said:
> Hi Christian,
>
> Sorry, I'm behind with your inital question.
>
> Comments below...
>
>
> Am 06.09.2012 17:00, schrieb Christian W. Damus:
>> Hi,
>>
>> Following up, I see in the debugger that the problem is that the
>> resource sent to the server containing my dynamic EPackage is, of
>> course, a UML profile resource. So, its root is a UML Profile
>> instance. The EPackage is in an EAnnotation contained in the Profile.
> I may misunderstand but you're not expecting this dynamic EPackage,
> which is a child of an instance object, to end up in CDO's package
> registry and be available for object creation/management, are you?
Yes, that's exactly it. It appears that I can add the profile
definition package to my client-side session's registry, although, as I
indicated in my original post, CDO seems to have raised its eyebrows at
it. It "works" at least insofar as the CDOEditor lets me create
instances of its EClasses in a resource.
>> When deserializng the resource, the server is trying to use a
>> CDOFactoryImpl to create an instance of the Profile eclass.
>> CDOFactoryImpl is mostly just an EFactoryImpl, and EFactoryImpl's
>> implementation of the create(EClass) method attempts to instantiate the
>> *superclass* of the requested eclass, without even first checking
>> whether the eclass itself has an instance class.
>>
>> Why on Earth would the generic EFactoryImpl start by trying to
>> instantiate the superclass instead of the class that it was asked to
>> instantiate? In this case, it's abstract (EModelElement) and so,
>> naturally, fails.
> Maybe it's related to the fact that the EPackage/EFactory pair is not
> being registered in the usual EMF/CDO infrastructure (e.g.
> CDOPackageRegistry of CDOSession or IRepository).
Yeah. It appears to be registered, but evidently it has problems. It
should be recognized exactly like a dynamic package in a *.ecore
resource, but it isn't. And I think that's just because the EPackage
is nested within UML content.
But the specific behaviour that I observed in the EFactoryImpl isn't a
CDO thing; it's an EMF thing. It doesn't make any sense to me, and I
should ask about it in a separate thread.
>> In any case, I wouldn't really expect to have the UML metamodel on the
>> server, would I?
> Well usually you would expect so. But not in the normal "instance
> space". A repository must have access to the used EPackages and must
> make them available (dynamically) to clients that don't have the
> original generated model at hand.
OK, that makes sense. I suppose that I'd have the same problem with
the persistence of UML models, if it were a problem of package
registration, because I'm using legacy mode, right? But I don't have a
problem storing UML resources.
>> I thought CDO didn't use EMF on the back-end.
> This old article still sums up the status quo correctly:
> http://thegordian.blogspot.de/2009/03/emf-on-server.html
That picture looks so much better! Wow. My understanding of things
was still stuck in 2008!
>> If it does, then maybe I have my server OSGi misconfigured?
> Hard to say, but I doubt it. Maybe you can write a small test case so
> that I can reproduce it here? Let me know if you need start pointers
> regarding our test framework. If you want we could also have a
> teamviewer session on your box.
You've given me a couple of ideas to follow up, so I'll do that and
then prepare a small test case if it doesn't pan out. I know that I
can package a minimal example that would work in a very simple ad hoc
test in the CDO UI. I shall have to see about the test framework;
obviously, it would be important to have an automated test if there's
something that needs fixing in the server.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>
>> Thanks,
>>
>> Christian
>>
>>
>> On 2012-09-06 00:23:18 +0000, Christian W. Damus said:
>>
>>> Hi,
>>>
>>> Using the Juno release of CDO, I have a problem with UML models in
>>> "legacy mode". Basic model structures all seem to work fine. The
>>> problem happens in dynamic EPackage definitions of UML profiles.
>>>
>>> Using the EMF dynamic_package extension point, I can register the Ecore
>>> package embedded within a UML profile (*.profile.uml resource) and EMF
>>> correctly loads and registers it at run-time. In the CDO UI, I can use
>>> the "CDO Package Registry" dialog to add this package to my session
>>> using the "Generated…" button. However, it appears and behaves
>>> differently than other packages:
>>>
>>> - the icon is a ghostly grey package, not light purple (legacy) or dark
>>> purple (native)
>>> - the Type column shows a question mark instead of legacy/native type
>>> - the Original column shows "UNKNOWN" instead of a legacy/native type
>>>
>>> Dynamic EPackages from *.ecore resources in show up correctly as
>>> DYNAMIC type with the package-on-a-page icon.
>>>
>>> I suspect that all this is indicative of the cause of my real problem,
>>> which is that I cannot commit instances of the EClasses in such a
>>> dynamic package into the repository. If I create a new root object in
>>> a resource that is an instance of one of these EClasses, representing a
>>> stereotype application on a UML element, then attempting to commit
>>> fails with a server-side exception (see below) that looks to me like
>>> transmission of the dynamic package to the repository results in an
>>> attempt to instantiate the EModelElement class, which is abstract.
>>>
>>> Questions:
>>>
>>> - am I doing something wrong in registering or using this dynamic package?
>>> - is this a known problem?
>>> - is this happening because the dynamic package is not the root of an
>>> Ecore resource, but
>>> rather nested within in an EAnnotation in a UML profile in a UML resource?
>>>
>>> Thanks,
>>>
>>> Christian
>>>
>>>
>>> -------- 8< --------
>>>
>>> !ENTRY org.eclipse.net4j 4 0 2012-09-05 20:16:26.560
>>> !MESSAGE The class 'EModelElement' is not a valid classifier
>>> !STACK 0
>>> java.lang.IllegalArgumentException: The class 'EModelElement' is not a
>>> valid classifier
>>> at org.eclipse.emf.ecore.impl.EcoreFactoryImpl.create(EcoreFactoryImpl.java:99)
>>> at org.eclipse.emf.ecore.impl.EFactoryImpl.create(EFactoryImpl.java:260)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:885)
>>>
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:922)
>>>
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFactory(XMLHandler.java:2180)
>>>
>>> ...
>>> at org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHandler.java:163)
>>> at
>>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501)
>>>
>>> ...
>>> at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
>>> at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:175)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:240)
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1505)
>>>
>>> at org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFUtil.java:305)
>>> at
>>> org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CDOModelUtil.java:519)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.read(CDOPackageUnitImpl.java:301)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.common.protocol.CDODataInputImpl.readCDOPackageUnit(CDODataInputImpl.java:115)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:142)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:95)
>>>
>>> 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)
>>>
>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
|
|
|
| Re: [CDO] Cannot commit UML stereotype instances [message #909154 is a reply to message #909132] |
Thu, 06 September 2012 12:17 |
| Eclipse User |
|
|
|
Aha! Eike, you are too quick to assume my innocence.
My server OSGi configuration totally didn't have the UML metamodel.
Now it does, and I have a simpler problem that should be easier to fix,
which would (I think) require changes in the server.
The server assumes that the resource it was sent containing an EPackage
to register has the EPackage as its root. But, it doesn't, because
it's a UML profile. Now that I get the Profile instance correctly
created by the CDOFactory, I have a CCE on attempt to cast a Profile as
an EPackage.
The EMF package registry on the client side knows the full URI of the
dynamic package, which is more than just the resource URI: it needs
the fragment part to identify the embedded EPackage. So, we should be
able to communicate that complete URI to the server so that it can use
the fragment to look up the embedded EPackage, right?
cW
-------- 8< --------
Caused by: java.lang.ClassCastException:
org.eclipse.uml2.uml.internal.impl.ProfileImpl cannot be cast to
org.eclipse.emf.ecore.EPackage
at org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFUtil.java:308)
at
org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CDOModelUtil.java:519)
at
org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.read(CDOPackageUnitImpl.java:301)
at
org.eclipse.emf.cdo.internal.common.protocol.CDODataInputImpl.readCDOPackageUnit(CDODataInputImpl.java:115)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:142)
...
|
|
|
| Re: [CDO] Cannot commit UML stereotype instances [message #909169 is a reply to message #909154] |
Thu, 06 September 2012 12:57 |
| Eclipse User |
|
|
|
Am 06.09.2012 18:17, schrieb Christian W. Damus:
> Aha! Eike, you are too quick to assume my innocence.
>
> My server OSGi configuration totally didn't have the UML metamodel. Now it does, and I have a simpler problem that
> should be easier to fix, which would (I think) require changes in the server.
>
> The server assumes that the resource it was sent containing an EPackage to register has the EPackage as its root.
> But, it doesn't, because it's a UML profile. Now that I get the Profile instance correctly created by the CDOFactory,
> I have a CCE on attempt to cast a Profile as an EPackage.
>
> The EMF package registry on the client side knows the full URI of the dynamic package, which is more than just the
> resource URI: it needs the fragment part to identify the embedded EPackage. So, we should be able to communicate
> that complete URI to the server so that it can use the fragment to look up the embedded EPackage, right?
Not sure about the "easier to fix" :P
But first I must fully understand the problem. I still have the feeling that you're hitting the point I already tried to
explain. A CDO repository has two very different "areas" for models (EPackages) and instances (CDOObjects). As EPackages
are EObjects you can certainly store them in the instance area (directly contained by resources, or indirectly, as in
your case). But then you must not expect that this EPackage is available in the same way as normal "model area
packages". In particular packages in the model area (repository package registry) are immutable once committed, while in
the instance area they were mutable and would have history associated. I think you start to see the semantic mismatch
here. I wonder if we can do something about this in CDO without completely redesigning one of the oldest and deepest
mechansims in CDO.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | |
| Re: [CDO] Cannot commit UML stereotype instances [message #909221 is a reply to message #909169] |
Thu, 06 September 2012 14:49 |
| Eclipse User |
|
|
|
Hi, Eike,
Yes, I understand the distinction that the repository makes between
packages as schema (frozen) and packages as data. That's not a problem.
The immutability of packages in the repository's registry isn't a
problem, either, because once a dynamic Ecore definition has been
defined, it's frozen in time, too. Defining the profile again
generates an entirely new EPackage, with a distinct namespace URI, that
would have to be uploaded to the repository when any instances of it
are created. So, that's all cool.
I think the problem could be solved relatively simply in the client
side: the only problem is that the EPackage is in a UML profile model.
So, if the client session simply extracts/copies it into its own Ecore
resource as a root element, it will appear to the rest of CDO as a
perfectly normal EPackage. The UML API client-side needs to have the
profile context of the EPackage, but the repository shouldn't need that.
I'll see if I can scratch something up to see how it works.
cW
On 2012-09-06 16:57:18 +0000, Eike Stepper said:
> Am 06.09.2012 18:17, schrieb Christian W. Damus:
>> Aha! Eike, you are too quick to assume my innocence.
>>
>> My server OSGi configuration totally didn't have the UML metamodel.
>> Now it does, and I have a simpler problem that should be easier to fix,
>> which would (I think) require changes in the server.
>>
>> The server assumes that the resource it was sent containing an EPackage
>> to register has the EPackage as its root. But, it doesn't, because
>> it's a UML profile. Now that I get the Profile instance correctly
>> created by the CDOFactory, I have a CCE on attempt to cast a Profile as
>> an EPackage.
>>
>> The EMF package registry on the client side knows the full URI of the
>> dynamic package, which is more than just the resource URI: it needs
>> the fragment part to identify the embedded EPackage. So, we should be
>> able to communicate that complete URI to the server so that it can use
>> the fragment to look up the embedded EPackage, right?
> Not sure about the "easier to fix" :P
>
> But first I must fully understand the problem. I still have the feeling
> that you're hitting the point I already tried to explain. A CDO
> repository has two very different "areas" for models (EPackages) and
> instances (CDOObjects). As EPackages are EObjects you can certainly
> store them in the instance area (directly contained by resources, or
> indirectly, as in your case). But then you must not expect that this
> EPackage is available in the same way as normal "model area packages".
> In particular packages in the model area (repository package registry)
> are immutable once committed, while in the instance area they were
> mutable and would have history associated. I think you start to see the
> semantic mismatch here. I wonder if we can do something about this in
> CDO without completely redesigning one of the oldest and deepest
> mechansims in CDO.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Cannot commit UML stereotype instances [message #909306 is a reply to message #909221] |
Thu, 06 September 2012 19:13 |
| Eclipse User |
|
|
|
Hi, Eike,
I have an experimental fix working on the client side. There are two
parts to the fix:
- distinguish between packages in the EMF registry that are declared on the
generated_package extension point and those that are declared on the
dynamic_package extension point. The latter end up with the
CDOPackageUnit.Type.UNKNOWN because we can't find the bundle ID (looking
on the wrong extension point)
- send only the EPackage, not anything that contains it (whether a
UML Profile or
anything else) to the server when sending packages to be registered
This makes dynamic packages (for example, in UML Profiles) that are
deployed in plug-ins and registered in EMF's package registry work as
expected in CDO.
Now I'm working on a further tweak to register the dynamic packages in
UML Profiles that are store in the repository (not deployed in a
plug-in and, therefore, not in EMF's package registry). This is partly
working: registration of the package is OK, but UML doesn't see
instances of the dynamic package as stereotype applications because
some traceability to the UML model is missing.
cW
On 2012-09-06 18:49:34 +0000, Christian W. Damus said:
> Hi, Eike,
>
> Yes, I understand the distinction that the repository makes between
> packages as schema (frozen) and packages as data. That's not a problem.
>
> The immutability of packages in the repository's registry isn't a
> problem, either, because once a dynamic Ecore definition has been
> defined, it's frozen in time, too. Defining the profile again
> generates an entirely new EPackage, with a distinct namespace URI, that
> would have to be uploaded to the repository when any instances of it
> are created. So, that's all cool.
>
> I think the problem could be solved relatively simply in the client
> side: the only problem is that the EPackage is in a UML profile model.
> So, if the client session simply extracts/copies it into its own Ecore
> resource as a root element, it will appear to the rest of CDO as a
> perfectly normal EPackage. The UML API client-side needs to have the
> profile context of the EPackage, but the repository shouldn't need that.
>
> I'll see if I can scratch something up to see how it works.
>
> cW
-------- 8< --------
|
|
| |
| Re: [CDO] Cannot commit UML stereotype instances [message #909350 is a reply to message #909309] |
Thu, 06 September 2012 22:03 |
| Eclipse User |
|
|
|
Hmm, well, I realized that, of course, the repository itself doesn't
need these annotations for dynamic EPackages in profiles stored in the
repository any more than it needed them for the EPackages registered in
plugin-deployed profiles (not store in the repository).
So, that fixes this IllegalStateException on the unresolvable proxy. I
now don't attempt to store cross-references from the EPackage to the
UML profile in the repository package registry.
And, everything seems to work correctly as I apply dynamic profiles to
models, apply stereotypes, and edit their properties. Other
transactions and views within the session see everything correctly.
A new problem now happens when I open a new CDO session and reload the
models in that new session. Now, all of the stereotype applications
are correctly loaded for stereotypes defined in profiles stored in the
repository, *but*, the UML API doesn't recognize them as applied
stereotypes. They have their correct references to their base elements
and the profile and its Ecore definition all look sound, with the
expected EAnnotations to trace from the Ecore to the UML.
Debugging it, I see that the problem is that the new session loaded the
dynamic package into the client-side registry from the repository. And
that package had the annotations for traceability from Ecore to UML
stripped out to resolve the unresolved proxy problem. The repository
doesn't need these annotations, but the client does. I need the client
either to be able to get correct EPackage (with the annotations) from
the repository, or else to load the package into the repository from
the UML profile resource stored in the repository. I'm not sure which
is easier. Being able to reference model resources from registered
packages in the repository seems like a useful capability, and would
fix this problem.
cW
On 2012-09-06 23:26:36 +0000, Christian W. Damus said:
> So close!
>
> I just have a problem in registering the dynamic package, from the UML
> profile, on the server side.
>
> The UML API requires some annotations in the ECore definition of a
> profile that trace back to the UML definitions. For example, an EClass
> has an EAnnotation that references the UML Stereotype that it
> represents. The problem is that when the client sends this EPackage to
> the server, the server tries to resolve all proxies, and it fails to
> resolve these references to elements in the UML model. However, I know
> that they should resolve, because the profile (in this case, the
> stored.profile.uml resource) is already committed in the repo.
>
> cW
>
>
> java.lang.IllegalStateException: Unresolvable proxy:
> cdo://repo1/stored.profile.uml#L13
> org.eclipse.net4j.signal.RemoteException:
> java.lang.IllegalStateException: Unresolvable proxy:
> cdo://repo1/stored.profile.uml#L13
> at
> org.eclipse.net4j.signal.RequestWithConfirmation.getRemoteException(RequestWithConfirmation.java:141)
>
> at
> org.eclipse.net4j.signal.RequestWithConfirmation.setRemoteException(RequestWithConfirmation.java:130)
>
> at
> org.eclipse.net4j.signal.SignalProtocol.handleRemoteException(SignalProtocol.java:467)
>
> at
> org.eclipse.net4j.signal.RemoteExceptionIndication.indicating(RemoteExceptionIndication.java:66)
>
> at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:57)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
> at org.eclipse.net4j.signal.Indication.execute(Indication.java:51)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>
> at java.lang.Thread.run(Thread.java:680)
|
|
|
| Re: [CDO] Cannot commit UML stereotype instances [message #909675 is a reply to message #909350] |
Fri, 07 September 2012 10:47 |
| Eclipse User |
|
|
|
OK, so the problem is that the resource-set used by the server to load
packages incoming from the client to be registered doesn't demand-load
resources for resolution of cross-resource references. This makes
sense, because the expectation is that a registered package would only
ever cross-reference to another registered package.
Even if we did make this work in the repository, it wouldn't work in
the client because the package registry in a CDOSession is shared by
all of the views and transactions in that session. Which instance of
the same UML profile resource in which view or transaction should the
one Ecore definition resolve its reference? That doesn't work.
So, stepping back, it looks like a possible solution for UML will be to
restructure the Ecore definitions of profiles when importing them into
the repository. The current annotation references from EClasses to
Stereotypes will be rewritten as detail strings that weakly reference
the stereotypes. No more cross-resource HREFs. Then, on the client
side, the UML API that needs to trace from an EClass to its defining
Stereotype can use the soft reference to resolve on-the-fly in the
correct resource-set context.
This should be fun!
Of course, all of this still needs the CDO client-side package registry
to extract an EPackage from its containing UML model to send to the
server for registration. That much I already have working, and that
will be the only change needed (besides properly handling EMF's
registration of dynamic packages, which I also have working). I hope
to work up these changes into a patch in the next week or so.
cW
On 2012-09-07 02:03:52 +0000, Christian W. Damus said:
> Hmm, well, I realized that, of course, the repository itself doesn't
> need these annotations for dynamic EPackages in profiles stored in the
> repository any more than it needed them for the EPackages registered in
> plugin-deployed profiles (not store in the repository).
>
> So, that fixes this IllegalStateException on the unresolvable proxy. I
> now don't attempt to store cross-references from the EPackage to the
> UML profile in the repository package registry.
>
> And, everything seems to work correctly as I apply dynamic profiles to
> models, apply stereotypes, and edit their properties. Other
> transactions and views within the session see everything correctly.
>
> A new problem now happens when I open a new CDO session and reload the
> models in that new session. Now, all of the stereotype applications
> are correctly loaded for stereotypes defined in profiles stored in the
> repository, *but*, the UML API doesn't recognize them as applied
> stereotypes. They have their correct references to their base elements
> and the profile and its Ecore definition all look sound, with the
> expected EAnnotations to trace from the Ecore to the UML.
>
> Debugging it, I see that the problem is that the new session loaded the
> dynamic package into the client-side registry from the repository. And
> that package had the annotations for traceability from Ecore to UML
> stripped out to resolve the unresolved proxy problem. The repository
> doesn't need these annotations, but the client does. I need the client
> either to be able to get correct EPackage (with the annotations) from
> the repository, or else to load the package into the repository from
> the UML profile resource stored in the repository. I'm not sure which
> is easier. Being able to reference model resources from registered
> packages in the repository seems like a useful capability, and would
> fix this problem.
>
> cW
|
|
|
Goto Forum:
Current Time: Sat Nov 08 15:08:27 EST 2025
Powered by FUDForum. Page generated in 0.07036 seconds |
Home