Kelvin,
The generator is not supposed to generate anything for the document root.
It's prevented by this code in class JavaGenerator:
if ("DocumentRoot".equals(genClass.getName()))
{
genClass.setDynamic(true); // Don't generate DocumentRoot class
break;
}
This tells the generator that the document root should be handled as a
dynamic DataObject.
So, you could probably fix this by adding a check for null as well in
JavaGenerator, but it may be better to instead change TypeHelper to also
use "DocumentRoot" as the name. The name is really not relevant in the RT
implementation. It's the xml name, ExtendedMetaData.getName(), of "" that
is used to identify a document root.
Frank.
"kelvin goodson" <[EMAIL PROTECTED]> wrote on 02/01/2007 12:04:23
PM:
> I'm currently trying to generate SDO classes exhibiting multiple
inheritance
> to test that the generator is doing the right thing in the presence of
such
> models. I can't describe these with an XSD, so I am building up the
models
> with DataObjects, submitting them to TypeHelper.define() and then
pinching
> code from the XSD2JavaGenerator to finish the job. However, there's a
> difference between the way TypeHelper.define and XSDHelper.define handle
> global elements, which is blocking me. XSDHelper puts its global
elements
> by default in a type called "DocumentRoot" but TypeHelper uses the new
open
> content property creation scheme and puts these properties in a type
with a
> null value for its name. The EMF generator doesn't like this and falls
over
> thus ...
>
> Exception in thread "main" java.lang.NullPointerException
> at
org.eclipse.emf.codegen.ecore.genmodel.impl.GenClassImpl.isEObject(
> GenClassImpl.java:831)
> at
> org.eclipse.emf.codegen.ecore.genmodel.impl.
> GenPackageImpl$SwitchHelper.initLocal
> (GenPackageImpl.java:2233)
> at
> org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl$SwitchHelper
> .<init>(GenPackageImpl.java:2215)
> at
> org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl.prepareCache(
> GenPackageImpl.java:2703)
> at
> org.eclipse.emf.codegen.ecore.genmodel.generator.
> GenPackageGeneratorAdapter.doPreGenerate
> (GenPackageGeneratorAdapter.java:136)
> at
>
org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.preGenerate
> (AbstractGeneratorAdapter.java:157)
> at org.eclipse.emf.codegen.ecore.generator.Generator.generate(
> Generator.java:327)
> at org.eclipse.emf.codegen.ecore.generator.Generator.generate(
> Generator.java:296)
> at
org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel(
> JavaGenerator.java:448)
> at org.apache.tuscany.sdo.generate.JavaGenerator.generatePackages(
> JavaGenerator.java:370)
> at
>
org.apache.tuscany.sdo.generate.MemoryModel2JavaGenerator.generateFromTypeDesc
> (MemoryModel2JavaGenerator.java:133)
> at
>
org.apache.tuscany.sdo.generate.MemoryModel2JavaGenerator.generateFromTypeList
> (MemoryModel2JavaGenerator.java:113)
> at
org.apache.tuscany.sdo.test.GenMultipleInheritanceTestClasses.run(
> GenMultipleInheritanceTestClasses.java:31)
> at
org.apache.tuscany.sdo.test.GenMultipleInheritanceTestClasses.main(
> GenMultipleInheritanceTestClasses.java:56)
>
> So I'm trying to figure out what my options are, and whether I need to
seek
> a fix in EMF, or find a way round this in our implementation. Any
thoughts?
>
> Regards, Kelvin.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
