John,
Comments below.
John J. Franey wrote:
On Thu, 17 Sep 2009 12:21:46 -0400, Ed Merks wrote:
John,
Comments below.
Thanks. I have a question, see below.
So, with the input I provided, the first call to ATI.next ought to
return a 'component' eobject.
Not sure what input you provided.
The input is this xml content:
<?xml version="1.0" encoding="UTF-8"?> <scr:component
xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" enabled="true"
factory="" immediate="false" name="Command Provider for Dictionary
Service" activate=""
deactivate=""
modified="">
<implementation class="jjjjjjjjjj"/>
<service/>
</scr:component>
Here is the iterator's value of eStructuralFeatures array whose length
is 4:
org.eclipse.emf.ecore.impl.EAttributeImpl@61328229 (name: mixed)
(ordered: true, unique: false, lowerBound: 0, upperBound: -1)
(changeable: true, volatile: false, transient: false,
defaultValueLiteral: null, unsettable: false, derived: false) (iD:
false)
org.eclipse.emf.ecore.impl.EReferenceImpl@26b056fd (name:
implementation) (ordered: true, unique: true, lowerBound: 1,
upperBound: 1) (changeable: true, volatile: true, transient: true,
defaultValueLiteral: null, unsettable: false, derived: false)
(containment: true, resolveProxies: false)
org.eclipse.emf.ecore.impl.EReferenceImpl@2a8e32b7 (name: service)
(ordered: true, unique: true, lowerBound: 0, upperBound: 1)
(changeable: true, volatile: true, transient: true,
defaultValueLiteral: null, unsettable: false, derived: false)
(containment: true, resolveProxies: false)
org.eclipse.emf.ecore.impl.EReferenceImpl@3aff8399 (name: reference)
(ordered: true, unique: true, lowerBound: 0, upperBound: -1)
(changeable: true, volatile: true, transient: true,
defaultValueLiteral: null, unsettable: false, derived: false)
(containment: true, resolveProxies: false)
It looks like the iterator retrieves the first 'implementation' and
'service' eObjects as result of interpreting the first element in
eStructuralFeatures. The second 'implementation' comes from
interpreting the second element of eStructuralFeatures. The second
'service' comes from interpreting the third element of
eStructuralFeatures. I can give details of this debugging session.
Its painstaking. I hope I don't have to do it.
I don't think it's possible for an object to be contained by more than
one containment feature.
Which stands in conflict with your understanding: the eStructuralFeatures
above, my analysis, or both?
An EObject can only have one eContainmentFeature so I'm just stating it
as a general impossibility.
But shouldn't all these other references be
marked as derived given they are derived from the mixed feature map (I
assume).
Your assumption may be correct. I did not originate the model. I hope
you don't mind me asking what led you to that assumption?
The XSDEcoreBuilder does this:
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ else if (isMixed)
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ {
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ eStructuralFeature.setDerived(true);
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ eStructuralFeature.setTransient(true);
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ eStructuralFeature.setVolatile(true);
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ }
so I
My other question is more of a clarification. When you say 'marked as
derived', I think you mean each of the EReferences above ought to have
the flag 'derived' set to 'true'.
Yes.
I wonder how the author of an ecore model would know to mark such
references as 'derived'.
Finally, what connects a 'derived field' to the associated feature map
and key?
Logic like this is EStructuralFeatureImpl
ÂÂÂÂÂ if (isDerived() &&
ÂÂÂÂÂÂÂÂÂÂÂ (((featureMapFeature =
ExtendedMetaData.INSTANCE.getMixedFeature(eClass)) != null &&
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ featureMapFeature != this) ||
ÂÂÂÂÂÂÂÂÂÂÂÂÂ ((featureMapFeature =
ExtendedMetaData.INSTANCE.getGroup(this)) != null)))
ÂÂÂÂÂ {
ÂÂÂÂÂÂÂ settingDelegate = new
InternalSettingDelegateFeatureMapDelegator(this, featureMapFeature);
I mean, when I look at the ecore xml file, I see a structural
feature element for one of the references above, but I can't see how
ecore knows how to generate the get method to reach into the map and what
key to use.
It's not obvious, but that's what it should do in a morel properly
derived from an XML Schema with mixed content.
So the question: is the iterator being initialized incorrectly
(incorrect content of eStructuralFeatures), or does it interpret
eStructuralFeatures incorrectly?
I think they fact they aren't derived is a problem. How did this model
arise?
I have to bring up that question with the person who originated the
model. From the plugin project's setup, it appears that the ecore file
is the source of the model.
Sounds like someone has been messing around a little bit.
Thanks again,
John
|