Home » Modeling » EMF » XSD -> ECore; internal missmatch (auto-creation)
XSD -> ECore; internal missmatch (auto-creation) [message #1507102] |
Thu, 11 December 2014 10:15 |
Rony Liemmukda 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.
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!
|
|
|
Re: XSD -> ECore; internal missmatch (auto-creation) [message #1507553 is a reply to message #1507102] |
Thu, 11 December 2014 18:42 |
Ed Merks Messages: 33218 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 -> ECore; internal missmatch (auto-creation) [message #1507627 is a reply to message #1507553] |
Thu, 11 December 2014 20:08 |
Rony Liemmukda Messages: 6 Registered: December 2014 |
Junior Member |
|
|
Hi Ed,
Thanks for the kind reply.
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 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 #1508273 is a reply to message #1508228] |
Fri, 12 December 2014 09:02 |
Ed Merks Messages: 33218 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 -&gt; ECore; internal missmatch (auto-creation) [message #1508686 is a reply to message #1508273] |
Fri, 12 December 2014 16:26 |
Rony Liemmukda Messages: 6 Registered: December 2014 |
Junior Member |
|
|
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.
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"
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;gt; ECore; internal missmatch (auto-creation) [message #1508789 is a reply to message #1508686] |
Fri, 12 December 2014 18:21 |
Ed Merks Messages: 33218 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;gt; ECore; internal missmatch (auto-creation) [message #1508811 is a reply to message #1508789] |
Fri, 12 December 2014 18:47 |
Rony Liemmukda 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
|
|
| | |
Goto Forum:
Current Time: Thu Sep 26 11:01:16 GMT 2024
Powered by FUDForum. Page generated in 0.04448 seconds
|