Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » XSD -> ECore; internal missmatch (auto-creation)
XSD -> ECore; internal missmatch (auto-creation) [message #1507102] Thu, 11 December 2014 10:15 Go to next message
Rony Liemmukda is currently offline Rony LiemmukdaFriend
Messages: 6
Registered: December 2014
Junior Member
Hi,

I'll try to explain, hopefully with simple words.

Approx 2 years ago I was using Xpand in combination with ECore transition from XML Schema (XSD). This was done dynamically, no persistent storage. (I used the org.eclipse.xtend.typesystem.xsd.XSDMetaModel class to do so).

The schema I used was pretty complex (AutoSAR v3.0.2), but it worked in an instant.

The usual workflow was like

* Go through objects
* Get the references
* Find the reference of interest
* Retrieve the EType
* Filter the attributes/elements
* Use "eGet( elements ) to retrieve the value of interest

So, this was working pretty fine. A few days ago I wanted to do the same as before. Got me the an AR 4.0.3 XSD, set up the project as before. It worked at first, until something strange happened.

The "eGet( attrib )" does not work on sub-elements anymore.

This, for example, works on the top level elements without a problem
EList<EAttribute> lstAttr;
		
		if ( eObj instanceof EClass ) {
			lstAttr = ((EClass) eObj).getEAttributes();
		} else {
			lstAttr = eObj.eClass().getEAttributes();
		}

		try {
			for ( EAttribute eAttrObj : lstAttr ) {
				if ( eObj instanceof EClass )  {
					System.out.println( eAttrObj.getName() + ": " + ((EClass)eObj).eGet( eAttrObj ) );
				} else {
					System.out.println( eAttrObj.getName() + ": " + eObj.eGet( eAttrObj ) );
				}
			}
		} catch ( Exception e ) {
			e.printStackTrace();
		}


However, going deeper into the structure, it spits out an exception like

"The feature 'shortName' is not a valid feature" (example based on the Tag "shortName" which is mapped in eCore as attribute.

index.php/fa/20204/0/


Well, since I first try to figure out what's going wrong I sat here two days single stepping and trying different access methods and files.

I found out that in deeper nested elements following statement became true

EClass MyClassObj = eRefObjArPckgs.getEReferenceType();
MyClassObj.getEAllAttributes() != MyClassObj.eClass().getEAllAttributes() 


So, even if I find an specific attribute (EStructualFeature), this is not found in the "sub-class" .eClass() !

eClassArPckg.getEAllAttributes(): [org.eclipse.emf.ecore.impl.EAttributeImpl@35059fcd (name: shortName) (ordered: true, unique: true, lowerBound: 1, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@13a6ac2e (name: category) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@38e711a6 (name: s) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@2dbf1522 (name: t) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@6fd99ff4 (name: uuid) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false)]

eClassArPckg.eClass().getEAllAttributes(): [org.eclipse.emf.ecore.impl.EAttributeImpl@31ef45e3 (name: name) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@6adede5 (name: instanceClassName) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: true, transient: false, defaultValueLiteral: null, unsettable: true, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@2d928643 (name: instanceClass) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: false, volatile: true, transient: true, defaultValueLiteral: null, unsettable: false, derived: true) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@5025a98f (name: defaultValue) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: false, volatile: true, transient: true, defaultValueLiteral: null, unsettable: false, derived: true) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@49993335 (name: instanceTypeName) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: true, transient: false, defaultValueLiteral: null, unsettable: true, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@20322d26 (name: abstract) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@192b07fd (name: interface) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false)]


So, why is that a problem?

The .eGet() does some evaluation which basically fails in certain points due to trying to find the feature behind .eClass() .

When, for example, I do

this.m_ModelMetaData.getElement(eClssArrPckg, ArXml4SchemaUrl, "SHORT-NAME") 


I get the same as from the Attribute-List of the class which is not behind .eClass(). Thus leading to an exception as well when invoking eGet(). But I verified that my package registry is basically correct.

To make things even more absurd I tried to access the elements directly with a XPand template, using the previously stated XSD MetaModel class

«DEFINE Root FOR  autosar403::Autosar»

«FILE "Debug.txt"»

«FOREACH this.arPackages.arPackage AS arPackage»
	«EXPAND ArPackageShortName FOR arPackage»
«ENDFOREACH»
«ENDFILE»

«ENDDEFINE»


«DEFINE ArPackageShortName FOR autosar403::ArPackage»
	ArPackage: «this.shortName.value»
	«FOREACH this.arPackages.arPackage AS arPackage»
		«EXPAND ArPackageShortName FOR arPackage»	
	«ENDFOREACH»
«ENDDEFINE»


Guess what?! It was working!

I verified all this strange behavior even with AR 3.2.1 XSD, so it's not a schema fault here...



So, basically my question is, does someone know how to resolve that strange problem? I need to access several attributes to get their values and the eGet() method seems to be the only one to do that.

Is a possible fix to be done within "org.eclipse.xtend.typesystem.xsd.XSDMetaModel" or in the EMF itself or should the EPackageRegistery be post-processed (HOW?)?


At least something must have changed on the internals on either one in the past two years...

Looking forward to some kind replies.

Thanks in advance!
  • Attachment: ArMapping.png
    (Size: 33.62KB, Downloaded 417 times)
Re: XSD -&gt; ECore; internal missmatch (auto-creation) [message #1507553 is a reply to message #1507102] Thu, 11 December 2014 18:42 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Rony,

Comments below.

On 11/12/2014 5:48 PM, Rony Liemmukda wrote:
> Hi,
>
> I'll try to explain, hopefully with simple words.
>
> Approx 2 years ago I was using Xpand in combination with ECore transition from XML Schema (XSD). This was done dynamically, no persistent storage. (I used the org.eclipse.xtend.typesystem.xsd.XSDMetaModel class to do so).
Note that I cannot comment on xtend?
>
> The schema I used was pretty complex (AutoSAR v3.0.2), but it worked in an instant.
>
> The usual workflow was like
>
> * Go through objects
> * Get the references
> * Find the reference of interest
> * Retrieve the EType
> * Filter the attributes/elements
> * Use "eGet( elements ) to retrieve the value of interest
>
> So, this was working pretty fine. A few days ago I wanted to do the same as before. Got me the an AR 4.0.3 XSD, set up the project as before. It worked at first, until something strange happened.
>
> The "eGet( attrib )" does not work on sub-elements anymore.
>
> This, for example, works on the top level elements without a problem
>
> EList<EAttribute> lstAttr;
>
> if ( eObj instanceof EClass ) {
> lstAttr = ((EClass) eObj).getEAttributes();
> } else {
> lstAttr = eObj.eClass().getEAttributes();
Keep in mind there's a very significant difference between
getEAttributes and getEAllAttributes and if you're using these for
reflections
> }
>
> try {
> for ( EAttribute eAttrObj : lstAttr ) {
> if ( eObj instanceof EClass ) {
> System.out.println( eAttrObj.getName() + ": " + ((EClass)eObj).eGet( eAttrObj ) );
Somehow this case makes no sense to me at all. If eObj is an EClass
and you get its eAttributes, you cannot use eObject.eGet() for one of
those attributes; it's the wrong meta-level...
> } else {
> System.out.println( eAttrObj.getName() + ": " + eObj.eGet( eAttrObj ) );
> }
> }
> } catch ( Exception e ) {
> e.printStackTrace();
> }
>
>
> However, going deeper into the structure, it spits out an exception like
>
> "The feature 'shortName' is not a valid feature" (example based on the Tag "shortName" which is mapped in eCore as attribute.
So certainly that wouldn't surprise me in cases where eObj is an EClass;
that just looks bogus as I said above.
>
>
>
>
> Well, since I first try to figure out what's going wrong I sat here two days single stepping and trying different access methods and files.
>
> I found out that in deeper nested elements following statement became true
>
>
> EClass MyClassObj = eRefObjArPckgs.getEReferenceType();
> MyClassObj.getEAllAttributes() != MyClassObj.eClass().getEAllAttributes()
I expect this is generally true. Again there in some total meta-level
confusion. Consider Java and you have some Class<?> x and you look
at x.getFields(), surely you'd not expect that x.getClass().getFields()
(which is just Class.class.getFields()) would have the same fields
(except when x == Class.class)....
>
>
> So, even if I find an specific attribute (EStructualFeature), this is not found in the "sub-class" .eClass() !
Now my brain totally hurts. You should focus on traversing an instance
model and not mix the meta and the instances up the way you're showing
above. It's completely nonsensical.
>
>
> eClassArPckg.getEAllAttributes(): [org.eclipse.emf.ecore.impl.EAttributeImpl@35059fcd (name: shortName) (ordered: true, unique: true, lowerBound: 1, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@13a6ac2e (name: category) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@38e711a6 (name: s) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@2dbf1522 (name: t) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@6fd99ff4 (name: uuid) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false)]
>
> eClassArPckg.eClass().getEAllAttributes(): [org.eclipse.emf.ecore.impl.EAttributeImpl@31ef45e3 (name: name) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@6adede5 (name: instanceClassName) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: true, transient: false, defaultValueLiteral: null, unsettable: true, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@2d928643 (name: instanceClass) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: false, volatile: true, transient: true, defaultValueLiteral: null, unsettable: false, derived: true) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@5025a98f (name: defaultValue) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: false, volatile: true, transient: true, defaultValueLiteral: null, unsettable: false, derived: true) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@49993335 (name: instanceTypeName) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: true, transient: false, defaultValueLiteral: null, unsettable: true, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@20322d26 (name: abstract) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false), org.eclipse.emf.ecore.impl.EAttributeImpl@192b07fd (name: interface) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (iD: false)]
>
>
> So, why is that a problem?
>
> The .eGet() does some evaluation which basically fails in certain points due to trying to find the feature behind .eClass() .
>
> When, for example, I do
>
>
> this.m_ModelMetaData.getElement(eClssArrPckg, ArXml4SchemaUrl, "SHORT-NAME")
>
>
> I get the same as from the Attribute-List of the class which is not behind .eClass(). Thus leading to an exception as well when invoking eGet(). But I verified that my package registry is basically correct.
>
> To make things even more absurd I tried to access the elements directly with a XPand template, using the previously stated XSD MetaModel class
>
>
> «DEFINE Root FOR autosar403::Autosar»
>
> «FILE "Debug.txt"»
>
> «FOREACH this.arPackages.arPackage AS arPackage»
> «EXPAND ArPackageShortName FOR arPackage»
> «ENDFOREACH»
> «ENDFILE»
>
> «ENDDEFINE»
>
>
> «DEFINE ArPackageShortName FOR autosar403::ArPackage»
> ArPackage: «this.shortName.value»
> «FOREACH this.arPackages.arPackage AS arPackage»
> «EXPAND ArPackageShortName FOR arPackage»
> «ENDFOREACH»
> «ENDDEFINE»
>
>
> Guess what?! It was working!
>
> I verified all this strange behavior even with AR 3.2.1 XSD, so it's not a schema fault here...
>
>
>
> So, basically my question is, does someone know how to resolve that strange problem? I need to access several attributes to get their values and the eGet() method seems to be the only one to do that.

Yes, and your generally pattern should be to visit some EObject x, to use

for (EStructuralFeature f : x.eClass().getEAllStructuralFeatures)
{
x.eGet(f);
}

No checking if x is an instance of an EClass and other bizzare stuff
like I see above. And being careful to use
eAllAttributes/eAllReferences/eAllStructuralFeatures so you visit all
attributes/references/features and not just the locally declared ones.
>
> Is a possible fix to be done within "org.eclipse.xtend.typesystem.xsd.XSDMetaModel" or in the EMF itself or should the EPackageRegistery be post-processed (HOW?)?
>
>
> At least something must have changed on the internals on either one in the past two years...
I don't get how the code you showed ever worked. Perhaps the newer
schemas make better use of inheritance for sharing common structure so
you eAttributes no longer visits all the data properly.
>
> Looking forward to some kind replies.
>
> Thanks in advance!


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: XSD -&gt; ECore; internal missmatch (auto-creation) [message #1507627 is a reply to message #1507553] Thu, 11 December 2014 20:08 Go to previous messageGo to next message
Rony Liemmukda is currently offline Rony LiemmukdaFriend
Messages: 6
Registered: December 2014
Junior Member
Hi Ed,

Thanks for the kind reply. Smile

Please find my comments below

>Ed Merks wrote on Thu, 11 December 2014 18:41
>Rony,

>Comments below.


>Note that I cannot comment on xtend?
This is basically a ready to use helper class which does all the metamodel transition and setting up the environment. I just mentioned it for eventual question about how I obtain the eCore model from XSD


>Keep in mind there's a very significant difference between
getEAttributes and getEAllAttributes and if you're using these for
reflections
yes, I got that part already. I used the first one to just obtain the "real" attributes in the model's element

Somehow this case makes no sense to me at all. If eObj is an EClass
and you get its eAttributes, you cannot use eObject.eGet() for one of
those attributes; it's the wrong meta-level...

[...]

So certainly that wouldn't surprise me in cases where eObj is an EClass;
that just looks bogus as I said above.

Explanation follows


I expect this is generally true. Again there in some total meta-level
confusion. Consider Java and you have some Class<?> x and you look
at x.getFields(), surely you'd not expect that x.getClass().getFields()
(which is just Class.class.getFields()) would have the same fields
(except when x == Class.class)....
Yes, I know that much Wink Sorry for the confusion, I tried to make my problem more clear. Guess I failed hard...


Now my brain totally hurts. You should focus on traversing an instance
model and not mix the meta and the instances up the way you're showing
above. It's completely nonsensical.
>
>

Ok, here the combined answer...
I was going for EAllStructuralFeatures() at first, since I thought I had done it like that two years ago. So, I saw the EReferences popping up as expected, went for one level down and looked for specific identifiers. So, when for example the shortName tag didn't show up I began to investigate why not. I tried with getETypeReference() (on the references) and got an EClass with the element in its EAttribute container. I even got the same object with getEAllStructuralFeatures() as well. So I popped a call to eGet() with that object on the EClass and caught an exception (as described earlier). "Funny", I thought... Since I got that element from its (that EClass) own collection. So, after further investigation I found out that eGet() accesses features from eClass(), which obviously doesn't contain these elements.

(Honestly, I have no access to that old code anymore and I currently try to redo what I did back then, sucessfully, within 15 minutes. Yes, I feel like an idiot that I don't get it done as easily as before. Maybe I am thinking too hard about what I am doing. I don't know....)





Yes, and your generally pattern should be to visit some EObject x, to use

for (EStructuralFeature f : x.eClass().getEAllStructuralFeatures)
{
x.eGet(f);
}

No checking if x is an instance of an EClass and other bizzare stuff
like I see above. And being careful to use
eAllAttributes/eAllReferences/eAllStructuralFeatures so you visit all
attributes/references/features and not just the locally declared ones.
>

I am pretty sure I did that at first (as written above). But, yes I did lose track which combinations I used during my error finding process... Well, just to make sure that I am not a complete idiot I will give that iteration another try when I am back in the office tomorrow. (You really make me unsure now whether I used 'eClass()' n my iteration or not... (I won't sleep good tonight :/ Guess I deserve it))

Thank you so far for your patience!!


EDIT:
NOW it just came to my mind like a nail to a magnet....!!!! I probably used that EReference feature directly instead of putting it into eGet() as parameter.. Let me check that to confirm my stupidity... before you provide another answer...

[Updated on: Thu, 11 December 2014 21:22]

Report message to a moderator

Re: XSD -&gt; ECore; internal missmatch (auto-creation) [message #1508228 is a reply to message #1507627] Fri, 12 December 2014 08:14 Go to previous messageGo to next message
Rony Liemmukda is currently offline Rony LiemmukdaFriend
Messages: 6
Registered: December 2014
Junior Member
Hi Ed,

me again with some positive results Smile ... I'm partly an idiot, since in the upper functions (I use specific functions for each type to keep the "garbage" low and the code specific to the element) I did it as you described but deviated in the sub-sequential ones (I'll change the code to be more generic and central instead of copy/pasting parts across functions to avoid that in the future).

Anyhow, correcting that led me to another occurrence from which I think led me to this deviation. The returned object was a FeatureEList; guess I was thinking that I did something wrong and tried another approach. So, a total fail on my part :/ (At least I'm 98% sure that I never saw a FeatureEList two years ago...)

Eventually, if you can confirm me the following approach to be a correct handling for that type of object, it would give me further confidence.

Very much thanks for the nudge in the right direction! I know that I did something terribly wrong, but I couldn't figure out what...


		/* we want to have an Arpackage*/
		for ( EStructuralFeature eObjFeat : eCoreObj.eClass().getEAllStructuralFeatures() )  {
				
			if ( EArxmlFeatures.ARPACKAGE.toString().equals(eObjFeat.getName())) {
				
				Object arPackageObj = eCoreObj.eGet(eObjFeat);
				
				if ( arPackageObj instanceof List<?> ) {				
					@SuppressWarnings("unchecked")
					FeatureEList<EObject> arPackage = (FeatureEList<EObject>) arPackageObj;
					/* I don't want to hard code get(0) */
					for ( EObject eFeatListObj : arPackage ) {
						parseArPackage( eFeatListObj );
					}
				} else {
					/* it must be an EObject, not a List<EObject> */
					parseArPackage( (EObject) arPackageObj );
				}
			} else {
				;
			}
		}

Re: XSD -&amp;gt; ECore; internal missmatch (auto-creation) [message #1508273 is a reply to message #1508228] Fri, 12 December 2014 09:02 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Rony,

Comments below.

On 12/12/2014 9:14 AM, Rony Liemmukda wrote:
> Hi Ed,
>
> me again with some positive results :) ... I'm partly an idiot, since
> in the upper functions (I use specific functions for each type to keep
> the "garbage" low and the code specific to the element) I did it as
> you described but deviated in the sub-sequential ones (I'll change the
> code to be more generic and central instead of copy/pasting parts
> across functions to avoid that in the future).
>
> Anyhow, correcting that led me to another occurrence from which I
> think led me to this deviation. The returned object was a
> FeatureEList; guess I was thinking that I did something wrong and
> tried another approach. So, a total fail on my part :/ (At least I'm
> 98% sure that I never saw a FeatureEList two years ago...)
That might well be. They're kind of ugly and arise from kind of ugly
aspects of XML Schema....
>
> Eventually, if you can confirm me the following approach to be a
> correct handling for that type of object, it would give me further
> confidence.
>
> Very much thanks for the nudge in the right direction! I know that I
> did something terribly wrong, but I couldn't figure out what...
>
>
> /* we want to have an Arpackage*/
> for ( EStructuralFeature eObjFeat :
> eCoreObj.eClass().getEAllStructuralFeatures() ) {
>
> if (
> EArxmlFeatures.ARPACKAGE.toString().equals(eObjFeat.getName())) {
>
> Object arPackageObj = eCoreObj.eGet(eObjFeat);
>
> if ( arPackageObj instanceof List<?> ) {
> @SuppressWarnings("unchecked")
> FeatureEList<EObject> arPackage =
> (FeatureEList<EObject>) arPackageObj;
You can't make this general assumption that if it's a list is must be a
feature map. You can use
org.eclipse.emf.ecore.util.FeatureMapUtil.isFeatureMap(EStructuralFeature)
to test if a feature represents a feature map. But the whole code looks
a little suspect. It's not clear if this is only supposed to work for
arpackage instances or not. Otherwise it's all kind of arbitrary, i.e.,
if the object happens to have a feature with some specific name, you'll
going start making assumptions about it...

In any case, I think you'll find
http://www.theserverside.com/news/1364302/Binding-XML-to-Java very
useful to read...
> /* I don't want to hard code get(0) */
> for ( EObject eFeatListObj : arPackage ) {
> parseArPackage( eFeatListObj );
> }
> } else {
> /* it must be an EObject, not a List<EObject> */
> parseArPackage( (EObject) arPackageObj );
> }
> } else {
> ;
> }
> }
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: XSD -&amp;gt; ECore; internal missmatch (auto-creation) [message #1508686 is a reply to message #1508273] Fri, 12 December 2014 16:26 Go to previous messageGo to next message
Rony Liemmukda is currently offline Rony LiemmukdaFriend
Messages: 6
Registered: December 2014
Junior Member
Hi Ed,

thanks for the reply Smile

******************************************
You can't make this general assumption that if it's a list is must be a
feature map. You can use
org.eclipse.emf.ecore.util.FeatureMapUtil.isFeatureMap(EStructuralFeature)
to test if a feature represents a feature map.

Well, that was my assumption... BUT it didn't work
When I do the following (test code)


for ( EStructuralFeature eObjFeat : eCoreObj.eClass().getEAllStructuralFeatures())  {
			
			if ( featureName.equals(eObjFeat.getName())) {		
				retVal = eCoreObj.eGet( eObjFeat );
				System.out.println( FeatureMapUtil.isFeatureMap( eObjFeat));
			} else {
				;
			}
		}


I always get a false, although it returns a feature list. However, if I try to apply this function on the object returned from eGet() and cast it forcefully to "EStructuralFeature" I will, obviously, catch a ClassCastException since I am not allowed to cast a "FeatureMap$FeatureEList" to that very type.

List works pretty well on that list type (I guess that's the problem here for the helper function to fail... {IMHO} ).



But the whole code looks a little suspect. It's not clear if this is only supposed to work for
arpackage instances or not. Otherwise it's all kind of arbitrary, i.e.,
if the object happens to have a feature with some specific name, you'll
going start making assumptions about it...


Sorry for showing suspicious code. Out of the context it might look very strange, but the code itself is written pretty generic and split up in different parser (one for each element of interest). Somehow I confuse people more when I try to write out-of-context pieces of code "non-confusing" Rolling Eyes
Other then that, the functionality in that piece of code works on other defined containers as well....



In any case, I think you'll find
Binding-XML-to-Java very
useful to read...
Oh yes, I read that before. It actually confused me... I understood the what was described there and it was a good read, but I couldn't fully apply it to my problems...
Re: XSD -&amp;amp;gt; ECore; internal missmatch (auto-creation) [message #1508789 is a reply to message #1508686] Fri, 12 December 2014 18:21 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Rony,

Comments below.

On 12/12/2014 5:26 PM, Rony Liemmukda wrote:
> Hi Ed,
>
> thanks for the reply :)
>
> ******************************************
> You can't make this general assumption that if it's a list is must be
> a feature map. You can use
> org.eclipse.emf.ecore.util.FeatureMapUtil.isFeatureMap(EStructuralFeature)
> to test if a feature represents a feature map.
> Well, that was my assumption... BUT it didn't work
> When I do the following (test code)
>
>
>
> for ( EStructuralFeature eObjFeat :
> eCoreObj.eClass().getEAllStructuralFeatures()) {
>
> if ( featureName.equals(eObjFeat.getName())) {
> retVal = eCoreObj.eGet( eObjFeat );
> System.out.println( FeatureMapUtil.isFeatureMap(
> eObjFeat));
> } else {
> ;
> }
> }
>
>
> I always get a false, although it returns a feature list. However, if
> I try to apply this function on the object returned from eGet() and
> cast it forcefully to "EStructuralFeature" I will, obviously, catch a
> ClassCastException since I am not allowed to cast a
> "FeatureMap$FeatureEList" to that very type.
This confused me. I can't do phantom debugging...
>
> List works pretty well on that list type (I guess that's the problem
> here for the helper function to fail... {IMHO} ).
Again, I'm clueless what you're trying to say.
>
> But the whole code looks a little suspect. It's not clear if this
> is only supposed to work for arpackage instances or not. Otherwise
> it's all kind of arbitrary, i.e., if the object happens to have a
> feature with some specific name, you'll going start making assumptions
> about it...
>
>
> Sorry for showing suspicious code. Out of the context it might look
> very strange, but the code itself is written pretty generic and split
> up in different parser (one for each element of interest). Somehow I
> confuse people more when I try to write out-of-context pieces of code
> "non-confusing" :roll: Other then that, the functionality in that
> piece of code works on other defined containers as well....
What can I say, it's all gremlins and phantoms to me...
>
>
> In any case, I think you'll find Binding-XML-to-Java very useful to
> read...
> Oh yes, I read that before. It actually confused me... I understood
> the what was described there and it was a good read, but I couldn't
> fully apply it to my problems...
What can I say?


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: XSD -&amp;amp;gt; ECore; internal missmatch (auto-creation) [message #1508811 is a reply to message #1508789] Fri, 12 December 2014 18:47 Go to previous messageGo to next message
Rony Liemmukda is currently offline Rony LiemmukdaFriend
Messages: 6
Registered: December 2014
Junior Member
Hi,

I think I can explain that in three sentences as well.
I am not getting a FeatureMap for that structural element, instead I am getting its inner class FeatureEList. That is why I check for a list instance. It might be the previously mentioned helper class which does this "deviation".
I saw from your link, your article, that you eventually/usually retrieve a FeatureMap for the kind of elements I am evaluating (which you try me to tell to take care of as well?!).

[Updated on: Fri, 12 December 2014 18:49]

Report message to a moderator

Re: XSD -&amp;amp;amp;gt; ECore; internal missmatch (auto-creation) [message #1509382 is a reply to message #1508811] Sat, 13 December 2014 06:24 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Rony,

Comments below.

On 12/12/2014 7:47 PM, Rony Liemmukda wrote:
> Hi,
>
> I think I can explain that in three sentences as well.
> I am not getting a FeatureMap for that structural element, instead I
> am getting its inner class FeatureEList. That is why I check for a
> list instance. It might be the previously mentioned helper class which
> does this "deviation".
I see. Don't read to much information into the specific implementation
classes. It's a little like observing in the debugger that you're
working with a LinkedList verses an ArrayList, but in the end you only
need to be considered (typically) it it's a List. So check things like
feature.isMany and if that's true, you can definite cast to List.
> I saw from your link, your article, that you eventually/usually
> retrieve a FeatureMap for the kind of elements I am evaluating.
Feature maps arise in many occasions and you can use
FeatureMapUtil.isFeatureMap to test for this.
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: XSD -> ECore; internal missmatch (auto-creation) [message #1552775 is a reply to message #1507102] Thu, 08 January 2015 10:04 Go to previous message
Rony Liemmukda is currently offline Rony LiemmukdaFriend
Messages: 6
Registered: December 2014
Junior Member
Ed,

sorry I forgot to thank you before going into vacation Embarrassed .
The M2M2T is finally working fine.

Thanks for the nudge in the right direction, your patience with me and the many helpful explanations Smile .

Kind regards,


Previous Topic:[CDO] Is CDOMergingConflictResolver really called back when conflicts occur ?
Next Topic:[EMF] [CDO] Use MappedResourceLocator with CDO
Goto Forum:
  


Current Time: Thu Mar 28 12:35:45 GMT 2024

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

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

Back to the top