| Not a valid classifier on windows standalone application [message #423941] |
Fri, 10 October 2008 11:28  |
Eclipse User |
|
|
|
Originally posted by: jack.glass.gmx.com
Hi,
I have a problem after upgrading from 2.3 to 2.4.1 in my standalone
application.
I have an Object "Command" which is directly derived from EObject.
Command is my root object from which all other objects from my
application are derived. This class is abstract so its not listed in
CommandFactoryImpl.
One thing is that it works when I call it from Eclipse but not for in my
standalone application on windows but on Linux.
So it works in Eclipse (win+linux), and linux standalone but not windows
standalone. I check the classpaths, etc. everything is the same.
I'm lost how can this be??
The exception which I get:
java.lang.IllegalArgumentException: The class 'Command' is not a valid
classifier
at command.actions.impl.CommandFactoryImpl.create(Unknown Source)
at
org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XM LHelperIm
pl.java:884)
at
org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XM LHelperIm
pl.java:920)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFa ctory(XML
Handler.java:2171)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFe atureType
(XMLHandler.java:2144)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHa ndler.jav
a:2020)
at
org.eclipse.emf.ecore.xmi.impl.XMIHandler.createObject(XMIHa ndler.jav
a:131)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLH andler.ja
va:1825)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XML Handler.j
ava:1023)
at
org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMI Handler.j
ava:87)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.jav
a:1001)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.jav
a:712)
at
org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHa ndler.jav
a:167)
at
org.apache.xerces.parsers.AbstractSAXParser.startElement(Abs tractSAXP
arser.java:477)
at
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyEle ment(Abst
ractXMLDocumentParser.java:220)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanSt artElemen
t(XMLDocumentFragmentScannerImpl.java:810)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$Fragme ntContent
Dispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1534 )
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDo cument(XM
LDocumentFragmentScannerImpl.java:338)
at
org.apache.xerces.parsers.XML11Configuration.parse(XML11Conf iguration
..java:827)
at
org.apache.xerces.parsers.XML11Configuration.parse(XML11Conf iguration
..java:757)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:148 )
at
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSA XParser.j
ava:1168)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:181)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl
..java:180)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.ja
va:1445)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.ja
va:1241)
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(Resour
ceSetImpl.java:255)
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(
ResourceSetImpl.java:270)
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(Resou
rceSetImpl.java:397)
|
|
|
|
| Re: Not a valid classifier on windows standalone application [message #423949 is a reply to message #423946] |
Fri, 10 October 2008 13:32  |
| Eclipse User |
|
|
|
Originally posted by: jack.glass.gmx.com
Hi ed,
>> I have a problem after upgrading from 2.3 to 2.4.1 in my standalone
>> application.
>> I have an Object "Command" which is directly derived from EObject.
>> Command is my root object from which all other objects from my
>> application are derived. This class is abstract so its not listed in
>> CommandFactoryImpl.
>>
>> One thing is that it works when I call it from Eclipse but not for in
>> my standalone application on windows but on Linux.
> That's always a good indication that plugin.xml extension registrations
> that are needed have been overlooked.
My standalone application is not using eclipse ide anymore (so no
plugins anymore). Just SWT+EMF.
I use for EMF all listed jars
http://wiki.eclipse.org/EMF/EMF_2.3/Standalone_Zip_Removal
(Just the 2.4.1 version of it).
>>
>> So it works in Eclipse (win+linux), and linux standalone but not
>> windows standalone. I check the classpaths, etc. everything is the same.
>>
>> I'm lost how can this be??
> Can you tell if a different resource factory is being used to create the
> resource in each case?
I use this command to initialize my EMF package in the standalone case.
CommandPackage navPackage = CommandPackage.eINSTANCE;
// Demand load the resource for this file.
resource = resourceSet.getResource(uri, true);
I works perfect under linux but not under window and also this worked in
2.3 but not in 2.4.1.
>>
>> The exception which I get:
>> java.lang.IllegalArgumentException: The class 'Command' is not a valid
>> classifier
>> at command.actions.impl.CommandFactoryImpl.create(Unknown Source)
>> at
>> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XM LHelperIm
>> pl.java:884)
> Normally it should never try to create an instance of an abstract type
> because the serialization will contain either an xsi:type or a QName to
> represent the concrete type that should be used. I suspect that the
> different options being used in each case are causing the problem....
>> at
In my file I have xsi:type statement but only with concret objects and
never with "command".
Any ideas what I can do to get more information why it tries to load
"Command"?
best regards,
jack
|
|
|
| Re: Not a valid classifier on windows standalone application [message #423951 is a reply to message #423949] |
Fri, 10 October 2008 13:46 |
 Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Jack,
Comments below.
Jack Glass wrote:
> Hi ed,
>>> I have a problem after upgrading from 2.3 to 2.4.1 in my standalone
>>> application.
>>> I have an Object "Command" which is directly derived from EObject.
>>> Command is my root object from which all other objects from my
>>> application are derived. This class is abstract so its not listed in
>>> CommandFactoryImpl.
>>>
>>> One thing is that it works when I call it from Eclipse but not for
>>> in my standalone application on windows but on Linux.
>> That's always a good indication that plugin.xml extension
>> registrations that are needed have been overlooked.
>
> My standalone application is not using eclipse ide anymore (so no
> plugins anymore). Just SWT+EMF.
>
> I use for EMF all listed jars
> http://wiki.eclipse.org/EMF/EMF_2.3/Standalone_Zip_Removal
> (Just the 2.4.1 version of it).
>
>>>
>>> So it works in Eclipse (win+linux), and linux standalone but not
>>> windows standalone. I check the classpaths, etc. everything is the
>>> same.
>>>
>>> I'm lost how can this be??
>> Can you tell if a different resource factory is being used to create
>> the resource in each case?
>
> I use this command to initialize my EMF package in the standalone case.
> CommandPackage navPackage = CommandPackage.eINSTANCE;
> // Demand load the resource for this file.
> resource = resourceSet.getResource(uri, true);
>
> I works perfect under linux but not under window and also this worked
> in 2.3 but not in 2.4.1.
Is there some way I could reproduce this myself?
>
>>>
>>> The exception which I get:
>>> java.lang.IllegalArgumentException: The class 'Command' is not a
>>> valid classifier
>>> at command.actions.impl.CommandFactoryImpl.create(Unknown
>>> Source)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XM LHelperIm
>>> pl.java:884)
>> Normally it should never try to create an instance of an abstract
>> type because the serialization will contain either an xsi:type or a
>> QName to represent the concrete type that should be used. I suspect
>> that the different options being used in each case are causing the
>> problem....
>>> at
> In my file I have xsi:type statement but only with concret objects and
> never with "command".
It's hard to make insightful comments with so little concrete to go on...
>
> Any ideas what I can do to get more information why it tries to load
> "Command"?
The stack trace implies it's handling the deserialization of a feature
for which there is no xsi:type or QName in the serialization to indicate
that something other than the feature's type should be used, so it ends
up using the feature's type which you say is abstract...
Given the unusual nature of the problem, OS-specific, it makes you start
to wonder about which JRE is used and even more importantly which
implementation of the JAXP APIs... If you could send me something that
reproduces the problem, I'd be happy to have a look...
>
> best regards,
> jack
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Not a valid classifier on windows standalone application [message #424053 is a reply to message #423951] |
Wed, 15 October 2008 11:28 |
| Eclipse User |
|
|
|
Originally posted by: jack.glass.gmx.com
Ed,
I found the problem. The problem was that a 3rd party tool had its own
xercesimpl.jar which caused the problem.
I removed the registration code from this jar file and now everything is
now working.
It is using an older xerces version.
Name: org/apache/xerces/impl/Version.class
Comment: Xerces-J 2.6.1
Implementation-Title: org.apache.xerces.impl.Version
Implementation-Version: 2.6.1
Implementation-Vendor: Apache Software Foundation
Implementation-URL: http://xml.apache.org/xerces2-j/
Name: org/xml/sax/
Comment: based on xml-commons external 1.2.01
Specification-Title: Simple API for XML
Specification-Vendor: David Megginson
Specification-Version: 2.0.1
Implementation-Title: org.xml.sax
Implementation-Version: 2.0.1
Implementation-Vendor: David Megginson
Implementation-URL: http://www.saxproject.org/
Name: org/w3c/dom/
Comment: based on xml-commons external 1.2.01
Specification-Title: Document Object Model, Level 2 Core
Specification-Vendor: World Wide Web Consortium
Specification-Version: 1.0
Implementation-Title: org.w3c.dom
Implementation-Version: 1.0
Implementation-Vendor: World Wide Web Consortium
Implementation-URL: http://www.w3c.org/DOM/
Name: javax/xml/parsers/
Comment: based on xml-commons external 1.2.01
Specification-Title: Java API for XML Processing
Specification-Version: 1.2
Specification-Vendor: Sun Microsystems Inc.
Implementation-Title: javax.xml.parsers
Implementation-Version: 1.2.01
Implementation-Vendor: Sun Microsystems Inc.
Implementation-URL: http://java.sun.com/xml/jaxp.html
Name: javax/xml/transform/
Comment: based on xml-commons external 1.2.01
Specification-Title: Java API for XML Processing
Specification-Version: 1.2
Specification-Vendor: Sun Microsystems Inc.
Implementation-Title: javax.xml.transform
Implementation-Version: 1.2.01
Implementation-Vendor: Sun Microsystems Inc.
Implementation-URL: http://java.sun.com/xml/jaxp.html
Name: org/apache/xerces/xni/
Comment: Xerces Native Interface
Specification-Title: Xerces Native Interface
Specification-Version: 1.1
Specification-Vendor: Apache Software Foundation
Implementation-Title: org.apache.xerces.xni
Implementation-Version: 1.1
Implementation-Vendor: Apache Software Foundation
Thx for your help.
Regards,
Jack
Ed Merks schrieb:
> Jack,
>
> Comments below.
>
> Jack Glass wrote:
>> Hi ed,
>>>> I have a problem after upgrading from 2.3 to 2.4.1 in my standalone
>>>> application.
>>>> I have an Object "Command" which is directly derived from EObject.
>>>> Command is my root object from which all other objects from my
>>>> application are derived. This class is abstract so its not listed in
>>>> CommandFactoryImpl.
>>>>
>>>> One thing is that it works when I call it from Eclipse but not for
>>>> in my standalone application on windows but on Linux.
>>> That's always a good indication that plugin.xml extension
>>> registrations that are needed have been overlooked.
>>
>> My standalone application is not using eclipse ide anymore (so no
>> plugins anymore). Just SWT+EMF.
>>
>> I use for EMF all listed jars
>> http://wiki.eclipse.org/EMF/EMF_2.3/Standalone_Zip_Removal
>> (Just the 2.4.1 version of it).
>>
>>>>
>>>> So it works in Eclipse (win+linux), and linux standalone but not
>>>> windows standalone. I check the classpaths, etc. everything is the
>>>> same.
>>>>
>>>> I'm lost how can this be??
>>> Can you tell if a different resource factory is being used to create
>>> the resource in each case?
>>
>> I use this command to initialize my EMF package in the standalone case.
>> CommandPackage navPackage = CommandPackage.eINSTANCE;
>> // Demand load the resource for this file.
>> resource = resourceSet.getResource(uri, true);
>>
>> I works perfect under linux but not under window and also this worked
>> in 2.3 but not in 2.4.1.
> Is there some way I could reproduce this myself?
>>
>>>>
>>>> The exception which I get:
>>>> java.lang.IllegalArgumentException: The class 'Command' is not a
>>>> valid classifier
>>>> at command.actions.impl.CommandFactoryImpl.create(Unknown
>>>> Source)
>>>> at
>>>> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XM LHelperIm
>>>> pl.java:884)
>>> Normally it should never try to create an instance of an abstract
>>> type because the serialization will contain either an xsi:type or a
>>> QName to represent the concrete type that should be used. I suspect
>>> that the different options being used in each case are causing the
>>> problem....
>>>> at
>> In my file I have xsi:type statement but only with concret objects and
>> never with "command".
> It's hard to make insightful comments with so little concrete to go on...
>>
>> Any ideas what I can do to get more information why it tries to load
>> "Command"?
> The stack trace implies it's handling the deserialization of a feature
> for which there is no xsi:type or QName in the serialization to indicate
> that something other than the feature's type should be used, so it ends
> up using the feature's type which you say is abstract...
>
> Given the unusual nature of the problem, OS-specific, it makes you start
> to wonder about which JRE is used and even more importantly which
> implementation of the JAXP APIs... If you could send me something that
> reproduces the problem, I'd be happy to have a look...
>>
>> best regards,
>> jack
|
|
|
Powered by
FUDForum. Page generated in 5.03940 seconds
] 
Search
Help
Register
Login
Home
