Eclipse Community Forums: M2M (model-to-model transformation) » java.lang.IllegalArgumentException: The feature 'lass' is not a valid feature

Home » Archived » M2M (model-to-model transformation) » java.lang.IllegalArgumentException: The feature 'lass' is not a valid feature

Show: Today's Messages :: Show Polls :: Message Navigator

java.lang.IllegalArgumentException: The feature 'lass' is not a valid feature [message #38803]

Thu, 17 May 2007 17:00

Eclipse User

Originally posted by: no_public_mail.mail.com

Hi all,

I'm moving this thread from EMF newsgroup as suggested. Below is what has
been discussed. Can anybody suggest anything on this issue ?
Thanks

Andry,

Yes, it sounds specific to ATL.

Andry wrote:
yes, it is creating DynamicEObjectImpl as I see on the debugger,
I suppose probably it is better to ask in m2m group then ?

"Ed Merks" <merks@ca.ibm.com> wrote in message
news:f2hupo$ont$1@build.eclipse.org...
Andry,

This looks like a serialization of an Ecore instance and in that case, the
deserializer should have created an instance of the generated Ecore model
where EModelElementImpl specializes the eObjectForURIFragmentSegment to
handle this specialized fragment path syntax. So I suspect that for some
reason it's creating a DynamicEObjectImpl instead, but I don't know ATL
well enough to know why that would happen. Normally all that's needed is
to ensure that the EcorePackage's eNsURI is registered, which happens as a
side effect of accessing EcorePackage.eINSTANCE and that normally happens
automatically since almost everything depends on Ecore and hence would
cause the EcorePackage to be initialized.

Andry wrote:
Hi all,

I'm really puzzled by this error which I do not seem to solve, at least
for the last hours.
Eclipse 3.2.1, EMF 2.2.0.v200609210005.
I'm launching ATL transformation programmatically and error happens while
ATL is loading one of meta-models, which was created with the default
Ecore editor in Eclipse.

I tracked down with debugger which line causes failure and it appears it
is the first line in the model with the super type:

<eClassifiers xsi:type="ecore:EClass" name="ServiceInterface"
eSuperTypes="#//Class
.../../../plugin/com.exigen.eclipse.common.model/models/comm on.ecore#//security/SecurableElement "/>

in particular the piece of code below from BasicEObjectImpl (see stack
trace) removes 'C' from 'Class'

public EObject eObjectForURIFragmentSegment(String uriFragmentSegment)
{
int dotIndex = uriFragmentSegment.indexOf(".");
if (dotIndex == -1)
{
String name = uriFragmentSegment.substring(1);
EStructuralFeature eStructuralFeature =
eClass().getEStructuralFeature(name);
if (eStructuralFeature == null)
{
throw new IllegalArgumentException("The feature '" + name + "' is not a
valid feature");
}
return (EObject)eGet(eStructuralFeature, false);
}

Stack trace:
java.lang.IllegalArgumentException: The feature 'lass' is not a valid
feature
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eObjectForURIFra gmentSegment(BasicEObjectImpl.java:313)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.getEObject( ResourceImpl.java:695)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.getEObject( ResourceImpl.java:671)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.setValueFromId(XML Handler.java:2522)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.setAttribValue(XML Handler.java:2450)
at
org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler.handleObjectAtt ribs(SAXXMIHandler.java:74)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFa ctory(XMLHandler.java:1940)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromTy peName(XMLHandler.java:1844)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHa ndler.java:1779)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLH andler.java:1587)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XML Handler.java:881)
at
org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMI Handler.java:82)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:860)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:627)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .startElement(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocume ntParser.emptyElement(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanStartElement(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(U nknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(Unknown
Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:179)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:179)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1094)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:900)
at
org.atl.engine.repositories.emf4atl.ASMEMFModel.loadASMEMFMo del(ASMEMFModel.java:331)
at
org.atl.eclipse.engine.AtlEMFModelHandler.loadModel(AtlEMFMo delHandler.java:122)
.... the rest skipped

Would appreciate any hints.
Thanks

Report message to a moderator

Re: [ATL] java.lang.IllegalArgumentException: The feature 'lass' is not a valid feature [message #38838 is a reply to message #38803]

Thu, 17 May 2007 19:19

Frédéric Jouault

Messages: 572
Registered: July 2009

Senior Member

Hello,

> I'm moving this thread from EMF newsgroup as suggested.

Ok, but we have a rule here: ATL-related posts should have an
[ATL]-prefixed subject ;-). I am adding it to my answer. Please,
remember this for your future posts.

> Below is what has
> been discussed. Can anybody suggest anything on this issue ?
> Thanks

Can you open your file with the EMF reflexive editor, or does it return
an error as well? If EMF returns an error even when not invoked from
ATL, I would suggest going back to the EMF newsgroup ;-).

It seems that you XMI file is malformed. I can see that you are trying
to read it with ATL, but was it created with ATL as well?

I am probably not the best EMF XMI expert you can find around here
(especially since you come from the EMF newsgroup :-)), but here is a
first guess: It seems to me that the EMF XMI reader might be confused by
the leading "...", which I would have expected to be "..". Is it
possible that an incorrect URI was supplied to EMF when the file was
originally serialized?

Regards,

Frédéric Jouault

>
>
> Andry,
>
> Yes, it sounds specific to ATL.
>
>
> Andry wrote:
> yes, it is creating DynamicEObjectImpl as I see on the debugger,
> I suppose probably it is better to ask in m2m group then ?
>
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:f2hupo$ont$1@build.eclipse.org...
> Andry,
>
> This looks like a serialization of an Ecore instance and in that case, the
> deserializer should have created an instance of the generated Ecore model
> where EModelElementImpl specializes the eObjectForURIFragmentSegment to
> handle this specialized fragment path syntax. So I suspect that for some
> reason it's creating a DynamicEObjectImpl instead, but I don't know ATL
> well enough to know why that would happen. Normally all that's needed is
> to ensure that the EcorePackage's eNsURI is registered, which happens as a
> side effect of accessing EcorePackage.eINSTANCE and that normally happens
> automatically since almost everything depends on Ecore and hence would
> cause the EcorePackage to be initialized.
>
>
> Andry wrote:
> Hi all,
>
> I'm really puzzled by this error which I do not seem to solve, at least
> for the last hours.
> Eclipse 3.2.1, EMF 2.2.0.v200609210005.
> I'm launching ATL transformation programmatically and error happens while
> ATL is loading one of meta-models, which was created with the default
> Ecore editor in Eclipse.
>
> I tracked down with debugger which line causes failure and it appears it
> is the first line in the model with the super type:
>
> <eClassifiers xsi:type="ecore:EClass" name="ServiceInterface"
> eSuperTypes="#//Class
> .../../../plugin/com.exigen.eclipse.common.model/models/comm on.ecore#//security/SecurableElement "/>
>
> in particular the piece of code below from BasicEObjectImpl (see stack
> trace) removes 'C' from 'Class'
>
> public EObject eObjectForURIFragmentSegment(String uriFragmentSegment)
> {
> int dotIndex = uriFragmentSegment.indexOf(".");
> if (dotIndex == -1)
> {
> String name = uriFragmentSegment.substring(1);
> EStructuralFeature eStructuralFeature =
> eClass().getEStructuralFeature(name);
> if (eStructuralFeature == null)
> {
> throw new IllegalArgumentException("The feature '" + name + "' is not a
> valid feature");
> }
> return (EObject)eGet(eStructuralFeature, false);
> }
>
> Stack trace:
> java.lang.IllegalArgumentException: The feature 'lass' is not a valid
> feature
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eObjectForURIFra gmentSegment(BasicEObjectImpl.java:313)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.getEObject( ResourceImpl.java:695)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.getEObject( ResourceImpl.java:671)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setValueFromId(XML Handler.java:2522)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setAttribValue(XML Handler.java:2450)
> at
> org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler.handleObjectAtt ribs(SAXXMIHandler.java:74)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFa ctory(XMLHandler.java:1940)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromTy peName(XMLHandler.java:1844)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHa ndler.java:1779)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLH andler.java:1587)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XML Handler.java:881)
> at
> org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMI Handler.java:82)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:860)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:627)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .startElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocume ntParser.emptyElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanStartElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
> Source)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(U nknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(Unknown
> Source)
> at javax.xml.parsers.SAXParser.parse(Unknown Source)
> at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:179)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:179)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1094)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:900)
> at
> org.atl.engine.repositories.emf4atl.ASMEMFModel.loadASMEMFMo del(ASMEMFModel.java:331)
> at
> org.atl.eclipse.engine.AtlEMFModelHandler.loadModel(AtlEMFMo delHandler.java:122)
> .... the rest skipped
>
> Would appreciate any hints.
> Thanks
>
>
>
>
>
>
>

Report message to a moderator

Re: [ATL] java.lang.IllegalArgumentException: The feature 'lass' is not a valid feature [message #38870 is a reply to message #38838]

Thu, 17 May 2007 19:28

Eclipse User

Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------020801050207070802090301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Fr

Report message to a moderator

Re: [ATL] java.lang.IllegalArgumentException: The feature 'lass' is not a valid feature [message #38899 is a reply to message #38870]

Thu, 17 May 2007 19:47

Frédéric Jouault

Messages: 572
Registered: July 2009

Senior Member

Ed,

> I made this comment on the EMF newsgroup about this:
>
> This looks like a serialization of an Ecore instance and in that
> case, the deserializer should have created an instance of the
> generated Ecore model where EModelElementImpl specializes the
> eObjectForURIFragmentSegment to handle this specialized fragment
> path syntax. So I suspect that for some reason it's creating a
> DynamicEObjectImpl instead, but I don't know ATL well enough to know
> why that would happen. Normally all that's needed is to ensure that
> the EcorePackage's eNsURI is registered, which happens as a side
> effect of accessing EcorePackage.eINSTANCE and that normally happens
> automatically since almost everything depends on Ecore and hence
> would cause the EcorePackage to be initialized.
>
> Of course without seeing what namespace is used for the "ecore" prefix I
> can't be sure if this really was a serialization of an Ecore instance.
> But the syntax certainly looks correct if it is...

As I said, what I wrote about the look of the reference was merely a
guess :-).

I am definitely waiting for an answer to my other questions (does it
work with the EMF reflexive editor?, and was it created with ATL?) to
investigate the issue further.

However, I am still surprised that the "path" part of the reference is ok:

..../../../plugin/com.exigen.eclipse.common.model/models/com mon.ecore

I would have expected to see *two*, not *three*, leading dots, and I can
easily understand why EMF would be confused about it. But if the three
dots are ok, I would be very interested to know what they mean.

Regards,

Frédéric Jouault

Report message to a moderator

Re: [ATL] java.lang.IllegalArgumentException: The feature 'lass' is not a valid feature [message #38924 is a reply to message #38899]

Thu, 17 May 2007 19:50

Frédéric Jouault

Messages: 572
Registered: July 2009

Senior Member

Hi,

Well, now I see four of them. This "three-then-four" dots issue looks
like a newsgroup-related issue, completed unrelated to the original
issue :-/.

Regards,

Frédéric Jouault

Frédéric Jouault wrote:
> Ed,
>
>
>> I made this comment on the EMF newsgroup about this:
>>
>> This looks like a serialization of an Ecore instance and in that
>> case, the deserializer should have created an instance of the
>> generated Ecore model where EModelElementImpl specializes the
>> eObjectForURIFragmentSegment to handle this specialized fragment
>> path syntax. So I suspect that for some reason it's creating a
>> DynamicEObjectImpl instead, but I don't know ATL well enough to know
>> why that would happen. Normally all that's needed is to ensure that
>> the EcorePackage's eNsURI is registered, which happens as a side
>> effect of accessing EcorePackage.eINSTANCE and that normally happens
>> automatically since almost everything depends on Ecore and hence
>> would cause the EcorePackage to be initialized.
>>
>> Of course without seeing what namespace is used for the "ecore" prefix I
>> can't be sure if this really was a serialization of an Ecore instance.
>> But the syntax certainly looks correct if it is...
>
> As I said, what I wrote about the look of the reference was merely a
> guess :-).
>
> I am definitely waiting for an answer to my other questions (does it
> work with the EMF reflexive editor?, and was it created with ATL?) to
> investigate the issue further.
>
> However, I am still surprised that the "path" part of the reference is ok:
>
> ..../../../plugin/com.exigen.eclipse.common.model/models/com mon.ecore
>
> I would have expected to see *two*, not *three*, leading dots, and I can
> easily understand why EMF would be confused about it. But if the three
> dots are ok, I would be very interested to know what they mean.
>
>
> Regards,
>
> Frédéric Jouault
>
>
>

Report message to a moderator

Re: [ATL] java.lang.IllegalArgumentException: The feature 'lass' is not a valid feature [message #38948 is a reply to message #38838]

Thu, 17 May 2007 20:00

Eclipse User

Originally posted by: no_public_mail.mail.com

Hi,

sorry about the subject, will prefix it next time.

This is ecore meta-model file, not meta-model instance, it opens OK with
ecore editor.
It has been created with ecore editor, then genmodel produced from it and
all model API code generated from it together with edit and editor code. No
errors during that process so I assume that XMI should be correct. It has
not been modified by hand after that.
Don't know about actual model instance loading because can't get to it until
current problem is resolved.

here is the head of the file with the line that breaks:

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="domain"
nsURI="http://exigengroup.com/data/domain" nsPrefix="domain">
<eClassifiers xsi:type="ecore:EClass" name="ModelElement" abstract="true"
eSuperTypes=" ../../../plugin/com.exigen.eclipse.common.model/models/commo n.ecore#//primitives/BaseNamedElement ">
<eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
<details key="documentation" value="Base meta-class for every element of
meta-model."/>
</eAnnotations>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="ServiceInterface"
eSuperTypes="#//Class
.../../../plugin/com.exigen.eclipse.common.model/models/comm on.ecore#//security/SecurableElement "/>

I will probably will try to play with this file tomorrow, may be using ATL
API, because I'm out of ideas right now.

Thank you.

"Fr

Report message to a moderator

Re: [ATL] java.lang.IllegalArgumentException: The feature 'lass' is not a valid feature [message #39086 is a reply to message #38948]

Fri, 18 May 2007 02:22

Frédéric Jouault

Messages: 572
Registered: July 2009

Senior Member

Hello,

I did some tests, but the only errors I manage to get are because I do
not have common.ecore.

Could you please send us your two .ecore files? You may simplify them to
the minimal version that still exhibits this behavior.

Regards,

Frédéric Jouault

Andry wrote:
> Hi,
>
> sorry about the subject, will prefix it next time.
>
> This is ecore meta-model file, not meta-model instance, it opens OK with
> ecore editor.
> It has been created with ecore editor, then genmodel produced from it and
> all model API code generated from it together with edit and editor code. No
> errors during that process so I assume that XMI should be correct. It has
> not been modified by hand after that.
> Don't know about actual model instance loading because can't get to it until
> current problem is resolved.
>
> here is the head of the file with the line that breaks:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="domain"
> nsURI="http://exigengroup.com/data/domain" nsPrefix="domain">
> <eClassifiers xsi:type="ecore:EClass" name="ModelElement" abstract="true"
> eSuperTypes=" ../../../plugin/com.exigen.eclipse.common.model/models/commo n.ecore#//primitives/BaseNamedElement ">
> <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
> <details key="documentation" value="Base meta-class for every element of
> meta-model."/>
> </eAnnotations>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="ServiceInterface"
> eSuperTypes="#//Class
> .../../../plugin/com.exigen.eclipse.common.model/models/comm on.ecore#//security/SecurableElement "/>
>
> I will probably will try to play with this file tomorrow, may be using ATL
> API, because I'm out of ideas right now.
>
> Thank you.
>
>
> "Frédéric Jouault" <frederic.jouault@univ-nantes.fr> wrote in message
> news:f2i9sp$d79$1@build.eclipse.org...
>> Hello,
>>
>>> I'm moving this thread from EMF newsgroup as suggested.
>> Ok, but we have a rule here: ATL-related posts should have an
>> [ATL]-prefixed subject ;-). I am adding it to my answer. Please, remember
>> this for your future posts.
>>
>>
>>> Below is what has
>>> been discussed. Can anybody suggest anything on this issue ?
>>> Thanks
>>
>> Can you open your file with the EMF reflexive editor, or does it return an
>> error as well? If EMF returns an error even when not invoked from ATL, I
>> would suggest going back to the EMF newsgroup ;-).
>>
>>
>> It seems that you XMI file is malformed. I can see that you are trying to
>> read it with ATL, but was it created with ATL as well?
>>
>>
>> I am probably not the best EMF XMI expert you can find around here
>> (especially since you come from the EMF newsgroup :-)), but here is a
>> first guess: It seems to me that the EMF XMI reader might be confused by
>> the leading "...", which I would have expected to be "..". Is it possible
>> that an incorrect URI was supplied to EMF when the file was originally
>> serialized?
>>
>>
>> Regards,
>>
>> Frédéric Jouault
>>
>>
>>>
>>> Andry,
>>>
>>> Yes, it sounds specific to ATL.
>>>
>>>
>>> Andry wrote:
>>> yes, it is creating DynamicEObjectImpl as I see on the debugger,
>>> I suppose probably it is better to ask in m2m group then ?
>>>
>>>
>>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>>> news:f2hupo$ont$1@build.eclipse.org...
>>> Andry,
>>>
>>> This looks like a serialization of an Ecore instance and in that case,
>>> the
>>> deserializer should have created an instance of the generated Ecore model
>>> where EModelElementImpl specializes the eObjectForURIFragmentSegment to
>>> handle this specialized fragment path syntax. So I suspect that for some
>>> reason it's creating a DynamicEObjectImpl instead, but I don't know ATL
>>> well enough to know why that would happen. Normally all that's needed is
>>> to ensure that the EcorePackage's eNsURI is registered, which happens as
>>> a
>>> side effect of accessing EcorePackage.eINSTANCE and that normally happens
>>> automatically since almost everything depends on Ecore and hence would
>>> cause the EcorePackage to be initialized.
>>>
>>>
>>> Andry wrote:
>>> Hi all,
>>>
>>> I'm really puzzled by this error which I do not seem to solve, at least
>>> for the last hours.
>>> Eclipse 3.2.1, EMF 2.2.0.v200609210005.
>>> I'm launching ATL transformation programmatically and error happens while
>>> ATL is loading one of meta-models, which was created with the default
>>> Ecore editor in Eclipse.
>>>
>>> I tracked down with debugger which line causes failure and it appears it
>>> is the first line in the model with the super type:
>>>
>>> <eClassifiers xsi:type="ecore:EClass" name="ServiceInterface"
>>> eSuperTypes="#//Class
>>> .../../../plugin/com.exigen.eclipse.common.model/models/comm on.ecore#//security/SecurableElement "/>
>>>
>>> in particular the piece of code below from BasicEObjectImpl (see stack
>>> trace) removes 'C' from 'Class'
>>>
>>> public EObject eObjectForURIFragmentSegment(String uriFragmentSegment)
>>> {
>>> int dotIndex = uriFragmentSegment.indexOf(".");
>>> if (dotIndex == -1)
>>> {
>>> String name = uriFragmentSegment.substring(1);
>>> EStructuralFeature eStructuralFeature =
>>> eClass().getEStructuralFeature(name);
>>> if (eStructuralFeature == null)
>>> {
>>> throw new IllegalArgumentException("The feature '" + name + "' is not a
>>> valid feature");
>>> }
>>> return (EObject)eGet(eStructuralFeature, false);
>>> }
>>>
>>> Stack trace:
>>> java.lang.IllegalArgumentException: The feature 'lass' is not a valid
>>> feature
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eObjectForURIFra gmentSegment(BasicEObjectImpl.java:313)
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.getEObject( ResourceImpl.java:695)
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.getEObject( ResourceImpl.java:671)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setValueFromId(XML Handler.java:2522)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setAttribValue(XML Handler.java:2450)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler.handleObjectAtt ribs(SAXXMIHandler.java:74)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFa ctory(XMLHandler.java:1940)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromTy peName(XMLHandler.java:1844)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHa ndler.java:1779)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLH andler.java:1587)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XML Handler.java:881)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMI Handler.java:82)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:860)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:627)
>>> at
>>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .startElement(Unknown
>>> Source)
>>> at
>>> com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocume ntParser.emptyElement(Unknown
>>> Source)
>>> at
>>> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanStartElement(Unknown
>>> Source)
>>> at
>>> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl$FragmentContentDispatcher.dispatch(Unknown
>>> Source)
>>> at
>>> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(Unknown
>>> Source)
>>> at
>>> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
>>> Source)
>>> at
>>> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
>>> Source)
>>> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(U nknown
>>> Source)
>>> at
>>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(Unknown
>>> Source)
>>> at javax.xml.parsers.SAXParser.parse(Unknown Source)
>>> at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:179)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:179)
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1094)
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:900)
>>> at
>>> org.atl.engine.repositories.emf4atl.ASMEMFModel.loadASMEMFMo del(ASMEMFModel.java:331)
>>> at
>>> org.atl.eclipse.engine.AtlEMFModelHandler.loadModel(AtlEMFMo delHandler.java:122)
>>> .... the rest skipped
>>>
>>> Would appreciate any hints.
>>> Thanks
>>>
>>>
>>>
>>>
>>>
>>>
>

Report message to a moderator

Re: java.lang.IllegalArgumentException: The feature 'lass' is not a valid feature [message #720319 is a reply to message #38803]

Tue, 30 August 2011 11:23

TANAKA Toshiya

Messages: 1
Registered: August 2011

Junior Member

Hi all,

I face same situation.
I launch ATL transformation programmatically and get an error while ATL was loading one of meta-models.
BasicEObjectImpl decapitates EClass name and IllegalArgumentException is throwed.
This is same as [message #38803]'s situation.

Additionally,
This exception is not always throwed. Sometimes ATL transformation is completed.
The meta-model has references refering other meta-models including Ecore.ecore.

I investigated the cause of this and got some hints to resolve this problem.

When the IllegalArgumentException is throwed, EClass causing the exception is loading with EPackage.
When the exception is not throwed, with EcorePackage.

Ecore.ecore is registered as this EPackage or EcorePackage with ResourceSet#packageRegistry. The Registring key is NSURI "http:/ /www.eclipse.org/emf/2002/Ecore".
This registering is done in EMFModelLoader#adaptMetaModel(ASMEMFModel model, ASMEMFModel metamodel).
The EPackage or EcorePackage is got from ASMEMFModel#referencedExtents.
ASMEMFModel#referencedExtents has meta-models which are refered by one of ATL loading meta-models.
This has 2 Ecore.ecores.
One is EPackege object , and another is EcorePackage object.
One is loaded from platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#, and another is loaded from http:/ /www.eclipse.org/emf/2002/Ecore.

ASMEMFModel#referencedExtents is the HashSet. So, no one knows iterating order.
This is why sometimes the exception is throwed.
While iterating ASMEMFModel#referencedExtents, EPackage is registered with ResourceSet#packageRegistry earlier than EcorePackage...It can be completed.
EcorePackage is registered earlier than EPackage...It throws the exception.

I override EMFModelLoader#adaptMetaModel(ASMEMFModel model, ASMEMFModel metamodel) like below. Is it OK?

	protected void adaptMetamodel(ASMEMFModel model, ASMEMFModel metamodel) throws IOException {
		super.adaptMetamodel(model, metamodel);
		Registry packageRegistry = resourceSet.getPackageRegistry();
		EPackage pack = (EPackage) packageRegistry.get(EcorePackage.eINSTANCE.getNsURI());
		if (!(pack instanceof EcorePackage)) {
			packageRegistry.put(EcorePackage.eINSTANCE.getNsURI(), EcorePackage.eINSTANCE);
		}
	}

It is causing to throw the exception that ResourceSet#packageRegistry has EPackage.
So, if ResourceSet#packageRegistry has EPackage, i overwrite it with EcorePackage.

And why ATL is implementated like that?

Regards,
TANAKA Toshiya

Report message to a moderator

Re: java.lang.IllegalArgumentException: The feature 'lass' is not a valid feature [message #720473 is a reply to message #720319]

Tue, 30 August 2011 16:40

Ed Willink

Messages: 7681
Registered: July 2009

Senior Member

Hi

The problem is a one-byte mis-alignment reading a model, so "lass" was
actually "class".

I think it may go away if you take great care to use only Java 5
throughout and/or avoid binary MTL files and/or rebuild everything very
forcefully.

I don't think I've seen this since moving to Indigo.

Regards

Ed Willink

On 30/08/2011 12:23, TANAKA Toshiya wrote:
> Hi all,
>
> I face same situation.
> I launch ATL transformation programmatically and get an error while
> ATL was loading one of meta-models.
> BasicEObjectImpl decapitates EClass name and IllegalArgumentException
> is throwed.
> This is same as [message #38803]'s situation.
>
> Additionally,
> This exception is not always throwed. Sometimes ATL transformation is
> completed.
> The meta-model has references refering other meta-models including
> Ecore.ecore.
>
> I investigated the cause of this and got some hints to resolve this
> problem.
>
> When the IllegalArgumentException is throwed, EClass causing the
> exception is loading with EPackage.
> When the exception is not throwed, with EcorePackage.
>
> Ecore.ecore is registered as this EPackage or EcorePackage with
> ResourceSet#packageRegistry. The Registring key is NSURI "http:/
> /www.eclipse.org/emf/2002/Ecore".
> This registering is done in EMFModelLoader#adaptMetaModel(ASMEMFModel
> model, ASMEMFModel metamodel).
> The EPackage or EcorePackage is got from ASMEMFModel#referencedExtents.
> ASMEMFModel#referencedExtents has meta-models which are refered by one
> of ATL loading meta-models.
> This has 2 Ecore.ecores.
> One is EPackege object , and another is EcorePackage object.
> One is loaded from
> platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#, and another
> is loaded from http:/ /www.eclipse.org/emf/2002/Ecore.
>
> ASMEMFModel#referencedExtents is the HashSet. So, no one knows
> iterating order.
> This is why sometimes the exception is throwed.
> While iterating ASMEMFModel#referencedExtents, EPackage is registered
> with ResourceSet#packageRegistry earlier than EcorePackage...It can be
> completed.
> EcorePackage is registered earlier than EPackage...It throws the
> exception.
>
>
> I override EMFModelLoader#adaptMetaModel(ASMEMFModel model,
> ASMEMFModel metamodel) like below. Is it OK?
>
> protected void adaptMetamodel(ASMEMFModel model, ASMEMFModel
> metamodel) throws IOException {
> super.adaptMetamodel(model, metamodel);
> Registry packageRegistry = resourceSet.getPackageRegistry();
> EPackage pack = (EPackage)
> packageRegistry.get(EcorePackage.eINSTANCE.getNsURI());
> if (!(pack instanceof EcorePackage)) {
> packageRegistry.put(EcorePackage.eINSTANCE.getNsURI(),
> EcorePackage.eINSTANCE);
> }
> }
>
> It is causing to throw the exception that ResourceSet#packageRegistry
> has EPackage.
> So, if ResourceSet#packageRegistry has EPackage, i overwrite it with
> EcorePackage.
>
> And why ATL is implementated like that?
>
>
>
> Regards,
> TANAKA Toshiya
>

Report message to a moderator