Home » Modeling » EMF » [xcore] Dynamic instance deserialization problem(A second Ecore package seems to be loaded during resource deserialization.)
|
Re: [xcore] Dynamic instance deserialization problem [message #1407754 is a reply to message #1407721] |
Wed, 13 August 2014 11:20 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Csaba,
Comments below.
On 13/08/2014 11:50 AM, Csaba Koncz wrote:
> Hi All,
>
> I am trying to perform validation on "dynamic" instances created from Xcore models.
>
> I went through the forum discussion mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=387010 and was able to define invariants in my Xcore model which worked well when using the generated package.
>
> However, when loading the dynamic instance XMI into the Reflective Ecore Editor, the invariants are no longer recognized.
No, there's no support for that.
>
> The reason is that the EPackage of the dynamic instance refers to a newly loaded Ecore package and not to the generated one. As a result EcoreUtil.isInvariant() returns false because it checks reference equality (and not EcorePackage.Literals.EBOOLEAN.equals(..))
It wouldn't matter because it's an EObject and EObject's don't override
equals...
>
> I am attaching a sample Xcore project that contains a SerializationTest (that needs to be run as a plugin test).
> The test methods of the test class demonstrate the two use cases: when
> using the generated classes, the operation is recognized as an invariant,
> in the "dynamic" case, it is not.
>
> What could be the solution?
The problem is that all the existing validation infrastructure pass
around strings that are expected to be passed to an interpreter, but
that doesn't work for Xcore because we must compile the Xbase body in
the full context of the containing Xcore constructs. So while one can
invoke operations dynamically, the underlying validation infrastructure
doesn't try to do that.
Trying to make this all work is several weeks of effort...
>
> Thank you in advance,
> Csaba
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: [xcore] Dynamic instance deserialization problem [message #1407770 is a reply to message #1407754] |
Wed, 13 August 2014 12:11 |
Csaba Koncz Messages: 49 Registered: July 2009 |
Member |
|
|
Hi Ed,
Thank you for the quick reply.
I think I was not clear enough.
I did not expect the framework to pick up my invariants and interpret them (which would be nice, of course, but saw from the previous forum posts that it is not implemented yet).
Instead, registered my own ValidationDelegate implementation and expected DynamicEClassValidator to provide me with the the expression string that needs to be interpreted. (I thought it might be not that difficult to implement Xbase evaluation, but after your comments I will reconsider that.)
The problem was that I did not get to the point where the ValidationDelegate.evaluate() method is invoked because of the issue described earlier: when inspecting the EOperations of the dynamic instance class,
some EBoolean data type is found which is not the same as EcorePackage.LITERALS.EBOOLEAN.
I think the Ecore.ecore package is somehow deserialized during the dynamic instance loading and I get references to the latter instances instead to the ones stored in EcorePackage.LITERALS.
Csaba
Ed Merks wrote on Wed, 13 August 2014 07:20Csaba,
Comments below.
On 13/08/2014 11:50 AM, Csaba Koncz wrote:
> Hi All,
>
> I am trying to perform validation on "dynamic" instances created from Xcore models.
>
> I went through the forum discussion mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=387010 and was able to define invariants in my Xcore model which worked well when using the generated package.
>
> However, when loading the dynamic instance XMI into the Reflective Ecore Editor, the invariants are no longer recognized.
No, there's no support for that.
>
> The reason is that the EPackage of the dynamic instance refers to a newly loaded Ecore package and not to the generated one. As a result EcoreUtil.isInvariant() returns false because it checks reference equality (and not EcorePackage.Literals.EBOOLEAN.equals(..))
It wouldn't matter because it's an EObject and EObject's don't override
equals...
>
> I am attaching a sample Xcore project that contains a SerializationTest (that needs to be run as a plugin test).
> The test methods of the test class demonstrate the two use cases: when
> using the generated classes, the operation is recognized as an invariant,
> in the "dynamic" case, it is not.
>
> What could be the solution?
The problem is that all the existing validation infrastructure pass
around strings that are expected to be passed to an interpreter, but
that doesn't work for Xcore because we must compile the Xbase body in
the full context of the containing Xcore constructs. So while one can
invoke operations dynamically, the underlying validation infrastructure
doesn't try to do that.
Trying to make this all work is several weeks of effort...
>
> Thank you in advance,
> Csaba
>
|
|
|
Re: [xcore] Dynamic instance deserialization problem [message #1407781 is a reply to message #1407770] |
Wed, 13 August 2014 12:30 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Csaba,
Comments below.
On 13/08/2014 2:11 PM, Csaba Koncz wrote:
> Hi Ed,
>
> Thank you for the quick reply.
> I think I was not clear enough.
>
> I did not expect the framework to pick up my invariants and interpret
> them (which would be nice, of course, but saw from the previous forum
> posts that it is not implemented yet).
>
> Instead, registered my own ValidationDelegate implementation and
> expected DynamicEClassValidator to provide me with the the expression
> string that needs to be interpreted. (I thought it might be not that
> difficult to implement Xbase evaluation, but after your comments I
> will reconsider that.)
I see, and for that the current implementation that expects models to
use the generated Ecore model is problematic... I don't think a
validation delegate specialized for Xcore (to invoke invariant
operations reflectively) would be so difficult, it's just the
generalizing all this to support things (classifier constraints) other
than invariants that's quite challenging...
>
> The problem was that I did not get to the point where the
> ValidationDelegate.evaluate() method is invoked because of the issue
> described earlier: when inspecting the EOperations of the dynamic
> instance class, some EBoolean data type is found which is not the same
> as EcorePackage.LITERALS.EBOOLEAN. I think the Ecore.ecore package is
> somehow deserialized during the dynamic instance loading and I get
> references to the latter instances instead to the ones stored in
> EcorePackage.LITERALS.
No, with Xcore we consistently use the development time version of
Ecore. Please open a bugzilla and I'll look at how to make
org.eclipse.emf.ecore.util.EcoreUtil.isInvariant(EOperation) permit the
development time version(s) of Ecore. Please include your test case in
the bugzilla.
>
> Csaba
>
>
> Ed Merks wrote on Wed, 13 August 2014 07:20
>> Csaba,
>>
>> Comments below.
>>
>> On 13/08/2014 11:50 AM, Csaba Koncz wrote:
>> > Hi All,
>> >
>> > I am trying to perform validation on "dynamic" instances created
>> from Xcore models.
>> >
>> > I went through the forum discussion mentioned in
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=387010 and was able to
>> define invariants in my Xcore model which worked well when using the
>> generated package.
>> >
>> > However, when loading the dynamic instance XMI into the Reflective
>> Ecore Editor, the invariants are no longer recognized.
>> No, there's no support for that.
>> > > The reason is that the EPackage of the dynamic instance refers
>> to a newly loaded Ecore package and not to the generated one. As a
>> result EcoreUtil.isInvariant() returns false because it checks
>> reference equality (and not EcorePackage.Literals.EBOOLEAN.equals(..))
>> It wouldn't matter because it's an EObject and EObject's don't
>> override equals...
>> >
>> > I am attaching a sample Xcore project that contains a
>> SerializationTest (that needs to be run as a plugin test).
>> > The test methods of the test class demonstrate the two use cases: when
>> > using the generated classes, the operation is recognized as an
>> invariant,
>> > in the "dynamic" case, it is not.
>> >
>> > What could be the solution?
>> The problem is that all the existing validation infrastructure pass
>> around strings that are expected to be passed to an interpreter, but
>> that doesn't work for Xcore because we must compile the Xbase body in
>> the full context of the containing Xcore constructs. So while one
>> can invoke operations dynamically, the underlying validation
>> infrastructure doesn't try to do that.
>>
>> Trying to make this all work is several weeks of effort...
>> >
>> > Thank you in advance,
>> > Csaba
>> >
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: [xcore] Dynamic instance deserialization problem [message #1407840 is a reply to message #1407800] |
Wed, 13 August 2014 15:39 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Csaba,
Yes, Xcore consistently uses the development time version of Ecore,
which is reflected in what you see when you export it.
On 13/08/2014 3:35 PM, Csaba Koncz wrote:
> Hi Ed,
>
> Thank you again, and here is the bugzilla:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=441688
>
> In the meantime I got a bit closer to the mystery, I think. I exported
> my xcore to ecore to see if the problem is Xcore related, and
> discovered that the ecore has references like these:
>
>
> eType="ecore:EDataType
> ../../org.eclipse.emf.ecore/model/Ecore.ecore#//EBoolean"
>
> If I replace this reference with
>
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"
>
> then the dynamic instance created from the Ecore model works as
> expected (i.e. the correct EBoolean from EcorePackage.Literals is used).
>
> Best regards,
> Csaba
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | | |
Goto Forum:
Current Time: Sat Sep 21 03:47:55 GMT 2024
Powered by FUDForum. Page generated in 0.04291 seconds
|