[news.eclipse.tools.emf] Re: Not a valid classifier on windows standalon

[Ed Merks <Ed.Merks@xxxxxxxxx>]

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(XMLHelperIm
> > > 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