You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by kelvin goodson <ke...@gmail.com> on 2007/02/01 18:04:23 UTC
[SDO Java] thoughts on generating classes from in memory models
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.
Re: [SDO Java] thoughts on generating classes from in memory models
Posted by Yang ZHONG <le...@gmail.com>.
I see TypeHelperImpl#defineOpenContentProperty creates(SDOUtil.createType)
DocumentRoot if not existed.
SDOUtil.createType creates DocumentRoot by DataObjectUtil.createDocumentRoot
().
DataObjectUtil.createDocumentRoot() has set XML name ("") while forgetting
eCore name ("DocumentRoot" normally).
It can be fixed by
documentRootEClass.setName("DocumentRoot");
On 2/1/07, kelvin goodson <ke...@gmail.com> wrote:
>
> 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.
>
--
Yang ZHONG
Re: [SDO Java] thoughts on generating classes from in memory models
Posted by Frank Budinsky <fr...@ca.ibm.com>.
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" <ke...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org