You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Ron Gavlin <rg...@yahoo.com> on 2006/07/05 16:09:51 UTC
Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException()
Greetings,
In order to support mixed static/dynamic models, I made changes to SDOXSDEcoreBuilder as well as the changes listed in my previous message. I'm investigating whether I can contribute these back to the community. I'll let you know when I have more information. The changes made to SDOXSDEcoreBuilder could just as easily have been applied to EMF's EcoreBuilder. I think EMF itself would probably benefit from this mixed-model support.
Do you have any thoughts about modifying the code generator to support this new base class? Also any thoughts about offering the ability to INDIVIDUALLY flag/annotate specific schema types as "extensible" to enable code-generation optimizations?
- Ron
----- Original Message ----
From: Ron Gavlin <rg...@yahoo.com>
To: tuscany-user@ws.apache.org
Sent: Friday, June 30, 2006 4:58:26 PM
Subject: Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException()
Frank,
Thanks, that helped.
I performed the following steps and the problem disappeared.
1. Added ExtensibleDataObject to the model (copied from DynamicDataObject)
2. Re-generated code from model into a work area and applied updates to relevant tuscany SDO classes [SDOFactory(Impl), SDOPackage(Impl)]
3. Copied DynamicDataObjectImpl to ExtensibleDataObjectImpl
4. Removed eStaticFeatureCount() method
5. Modified ExtensibleDataObjectImpl eStaticClass() and FactoryImpl.basicCreate to work with ExtensibleDataObjectImpls.
6. Modified my "InfoTypeImpl" class to extend ExtensibleDataObjectImpl instead of DataObjectImpl.
7. Executed XMLHelper load test to ensure the data object loads successfully using my mixed static/dynamic model...worked like a champ.
What option were you thinking of adding to the code generator to trigger using this new base class? Along with this course-grained approach, does it also make sense to offer the ability to INDIVIDUALLY flag/annotate specific schema types as "extensible"? Is there a significant performance/memory win using a DataObjectImpl vs. ExtensibleDataObjectImpl?
Thanks for all your help.
- Ron
----- Original Message ----
From: Frank Budinsky <fr...@ca.ibm.com>
To: tuscany-user@ws.apache.org
Sent: Friday, June 30, 2006 2:17:58 PM
Subject: Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException()
A little more background:
In EMF:
1. BasicEObjectImpl is a base implementation of the EObject interface. It
doesn't allocate any storage - it expects subclasses to do that.
2. EObjectImpl is the EMF default base class for generated classes. It is
a flexible implementation that allows the generated classes to be extended
by dynamic types.
3. DynamicEObjectImpl extends EObjectImpl to optimize a few things for the
pure-dynamic case.
4. EDataObjectImpl is a subclass of EObjectImpl that also implements the
SDO DataObject interface - in Tuscany we don't have separate
implementation classes to implement the DataObject interface because all
our implementation classes are for that purpose.
in Tuscany:
1. DataObjectImpl is a subclass of EMF's BasicEObjectImpl that implements
the DataObject interface and allocates the absolute minimum storage.
Unlike EObjectImpl, which is an analous class for EMF (EObject's), it is
not intended to be extended by dynamic types.
2. DynamicDataObjectImpl is analogous to DynamicEObjectImpl in EMF, but
for DataObjects.
So, the ExtensibleDataObjectImpl class I've suggested is something between
DataObjectImpl and DynamicDataObjectImpl that would be the DataObject
equivalent of EObjectImpl.
I hope this helps.
Frank.
Ron Gavlin <rg...@yahoo.com> wrote on 06/30/2006 01:12:58 PM:
> Frank,
>
> Does the proposed relationship between ExtensibleDataObjectImpl and
> DataObjectImpl somewhat mirror the relationship between EMF classes
> EObjectImpl and BasicEObjectImpl? At first glance, it appears
> EObjectImpl adds, amongst other things, support for this dynamic
> EClass. Would I look at the EMF/SDO 1.0 EDataObjectImpl class (which
> extends EObjectImpl) to get some ideas?
>
> - Ron
>
> ----- Original Message ----
> From: Ron Gavlin <rg...@yahoo.com>
> To: tuscany-user@ws.apache.org
> Sent: Friday, June 30, 2006 12:35:21 PM
> Subject: Re: DataObjectImpl.setEClass(EClass) throws
> UnsupportedOperationException()
>
>
> Hi Frank,
>
> I added JIRA feature request "TUSCANY-513" to track this issue.
> Unfortunately, I don't think I have the EMF experience required to
> whip-up such a class. Off the top of your head, do you have an idea
> what methods the class would probably need to implement to get the job
done?
>
> - Ron
>
> ----- Original Message ----
> From: Frank Budinsky <fr...@ca.ibm.com>
> To: tuscany-user@ws.apache.org
> Sent: Friday, June 30, 2006 12:05:34 PM
> Subject: Re: DataObjectImpl.setEClass(EClass) throws
> UnsupportedOperationException()
>
>
> Hi Ron,
>
> Looking at this, it looks like the problem is that you're trying to
create
> dynamic subclasses of statically generated types. The bad news is that
> Tuscany doesn't currently support that. The good news is that it's not
too
> hard to add the support.
>
> The problem is that currently Tuscany only has these two primary
> DataObject implementation classes:
>
> 1. DataObjectImpl - is the base class used for statically generated
types.
> It is highly tuned for performance and footprint, so, unlike the base
> class in SDO1 (actually EMF) it doesn't support dynamic extensions.
>
> 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It
is
> designed for pure dynamic types, not a mixture of static and dynamic.
>
> To support what you want, we will need another base class, say
> ExtensibleDataObjectImpl, that is quite similar to
DynamicDataObjectImpl,
> but doesn't make the assumption that eStaticFeatureCount() is 0. My
guess
> is that there are only a few simple method overrides needed in this
class.
> Maybe you would like to try to prototype such a class yourself and hand
> modify your generated classes to extend from it? If you did that and
> tested it, you could submit a patch and we could then very quickly add a
> generator option to use it (maybe even make it the default). If you'd
like
> to help with this, it would be very much appreciated!
>
> At any rate, you should probably open a JIRA feature request for this.
>
> Thanks,
> Frank
>
> Ron Gavlin <rg...@yahoo.com> wrote on 06/30/2006 10:13:44 AM:
>
> > Frank,
> >
> > I am working with a mixed static/dynamic model similar to the one
> > listed at the bottom of this post. The http://example.org/ord
> > namespace is statically registered and has code-generated classes. The
> > http://example.org/info/zipcode and http://example.org/info/street
> > namespaces are dynamically registered with no code-generated
> > classes. When I attempt to load the Sample Instance (chapter04.xml),
> > I receive an UnsupportedOperationException thrown from
> > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the
> > exception is an instance of "InfoTypeImpl" from the "ord"
> > namespace/ePackage. The EClass parameter is "InfoType" from the
> > "zipcode" namespace. This instance document loads fine using EMF/SDO
> > 1.0. Any suggestions I can try to work-around this problem?
> >
> > - Ron
> >
> >
> > Sample Instance (chapter04.xml)
> > <ord:order xmlns:ord="<http://example.org/ord>";;;;
> > xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>";;;;
> > xsi:schemaLocation="<http://example.org/ord> chapter04ord1.xsd">
> > <ord:number>123ABBCC123</ord:number>
> > <ord:customer>
> > <ord:name>Pat Walmsley</ord:name>
> > <ord:number>15465</ord:number>
> > <info xsi:type="ns1:InfoType" xmlns=""
> > xmlns:ns1="<http://example.org/info/zipcode>";;;;>
> > <zipcode>21043</zipcode>
> > </info>
> > </ord:customer>
> > <ord:customer>
> > <ord:name>Priscilla Walmsley</ord:name>
> > <ord:number>15466</ord:number>
> > <info xsi:type="ns1:InfoType" xmlns=""
> > xmlns:ns1="<http://example.org/info/street>";;;;>
> > <street>341 Duckworth Way</street>
> > </info>
> > </ord:customer>
> > <ord:items>
> > <product>
> > <number>557</number>
> > <name>Short-Sleeved Linen Blouse</name>
> > <size system="US-DRESS">10</size>
> > <color value="blue"/>
> > </product>
> > </ord:items>
> > </ord:order>
> > Schema Document 1 (chapter04ord1.xsd)
> > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;
> > targetNamespace="<http://example.org/ord>";;;;;
> > xmlns="<http://example.org/ord>";;;;;
> > xmlns:prod="<http://example.org/prod>";;;;;
> > elementFormDefault="qualified">
> > <xsd:import namespace="<http://example.org/prod>";;;;;
> > schemaLocation="chapter04prod.xsd"/>
> > <xsd:simpleType name="OrderNumType">
> > <xsd:restriction base="xsd:string"/>
> > </xsd:simpleType>
> > <xsd:complexType name="InfoType"/>
> > <xsd:complexType name="CustomerType">
> > <xsd:sequence>
> > <xsd:element name="name" type="CustNameType"/>
> > <xsd:element name="number" type="xsd:integer"/>
> > <xsd:element name="info" type="InfoType" form="unqualified"/>
> > </xsd:sequence>
> > </xsd:complexType>
> > <xsd:simpleType name="CustNameType">
> > <xsd:restriction base="xsd:string"/>
> > </xsd:simpleType>
> > <xsd:element name="order" type="OrderType"/>
> > <xsd:complexType name="OrderType">
> > <xsd:sequence>
> > <xsd:element name="number" type="OrderNumType"/>
> > <xsd:element name="customer" type="CustomerType"
> > maxOccurs="unbounded"/>
> > <xsd:element name="items" type="prod:ItemsType"/>
> > </xsd:sequence>
> > </xsd:complexType>
> > </xsd:schema>
> > Schema Document 2 (chapter04infozipcode.xsd)
> > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;
> > xmlns:ord="<http://example.org/ord>";;;;;
> > xmlns="<http://example.org/info/zipcode>";;;;;
> > targetNamespace="<http://example.org/info/zipcode>";;;;;
> > elementFormDefault="unqualified">
> > <xsd:import namespace="<http://example.org/ord>";;;;;
> > schemaLocation="chapter04ord1.xsd"/>
> > <xsd:complexType name="InfoType">
> > <xsd:complexContent>
> > <xsd:extension base="ord:InfoType">
> > <xsd:sequence>
> > <xsd:element name="zipcode" type="xsd:string"/>
> > </xsd:sequence>
> > </xsd:extension>
> > </xsd:complexContent>
> > </xsd:complexType>
> > </xsd:schema>
> > Schema Document 3 (chapter04infostreet.xsd)
> > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;
> > xmlns:ord="<http://example.org/ord>";;;;;
> > xmlns="<http://example.org/info/street>";;;;;
> > targetNamespace="<http://example.org/info/street>";;;;;
> > elementFormDefault="unqualified">
> > <xsd:import namespace="<http://example.org/ord>";;;;;
> > schemaLocation="chapter04ord1.xsd"/>
> > <xsd:complexType name="InfoType">
> > <xsd:complexContent>
> > <xsd:extension base="ord:InfoType">
> > <xsd:sequence>
> > <xsd:element name="street" type="xsd:string"/>
> > </xsd:sequence>
> > </xsd:extension>
> > </xsd:complexContent>
> > </xsd:complexType>
> > </xsd:schema>
> > Schema Document 4 (chapter04prod.xsd)
> > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;
> > xmlns="<http://example.org/prod>";;;;;
> > targetNamespace="<http://example.org/prod>";;;;;
> > elementFormDefault="unqualified">
> > <xsd:complexType name="ItemsType">
> > <xsd:sequence>
> > <xsd:element name="product" type="ProductType"/>
> > </xsd:sequence>
> > </xsd:complexType>
> > <xsd:complexType name="ProductType">
> > <xsd:sequence>
> > <xsd:element name="number" type="xsd:integer"/>
> > <xsd:element name="name" type="xsd:string"/>
> > <xsd:element name="size" type="SizeType"/>
> > <xsd:element name="color" type="ColorType"/>
> > </xsd:sequence>
> > </xsd:complexType>
> > <xsd:complexType name="SizeType">
> > <xsd:simpleContent>
> > <xsd:extension base="xsd:integer">
> > <xsd:attribute name="system" type="xsd:string"/>
> > </xsd:extension>
> > </xsd:simpleContent>
> > </xsd:complexType>
> > <xsd:complexType name="ColorType">
> > <xsd:attribute name="value" type="xsd:string"/>
> > </xsd:complexType>
> > </xsd:schema>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException()
Posted by Frank Budinsky <fr...@ca.ibm.com>.
That's probably a good idea. Making flexibility the default and optimal
performance an option is probably the best approach.
Frank.
Ron Gavlin <rg...@yahoo.com> wrote on 07/05/2006 12:46:29 PM:
> What do you think about making "extensible" the default behavior and
> adding an option "OPTION_NOT_EXTENSIBLE" or "OPTION_NO_EXTENSION"
> for those folks that don't want the "extensible" overhead?
>
> ----- Original Message ----
> From: Frank Budinsky <fr...@ca.ibm.com>
> To: tuscany-user@ws.apache.org
> Cc: tuscany-user@ws.apache.org
> Sent: Wednesday, July 5, 2006 12:06:45 PM
> Subject: Re: DataObjectImpl.setEClass(EClass) throws
> UnsupportedOperationException()
>
>
> Ron Gavlin <rg...@yahoo.com> wrote on 07/05/2006 10:09:51 AM:
>
> > Greetings,
> >
> > In order to support mixed static/dynamic models, I made changes to
> > SDOXSDEcoreBuilder as well as the changes listed in my previous
> > message. I'm investigating whether I can contribute these back to
> > the community. I'll let you know when I have more information.
> That would be great if you can. If so, open a JIRA for the issue and
> attach a patch.
>
> > The changes made to SDOXSDEcoreBuilder could just as easily have been
> > applied to EMF's EcoreBuilder. I think EMF itself would probably
> > benefit from this mixed-model support.
> Since you haven't said exactly what your change to SDOXSDEcoreBuilder
> actually does, I can't really comment on whether or not it would be a
good
> addition to EMF itself. If it's some kind of annotation to choose on a
> per-complexType basis whether to support a mixed dynamic/static base
> class, I think that since EMF currently has no static-only optimized
base
> class, I'm not sure they'd want it there ... but you might want to
suggest
> it on the EMF newsgroup to let them comment.
>
> >
> > Do you have any thoughts about modifying the code generator to
> > support this new base class?
> Once we have the ExtensibleDataObjectImpl base class available, then I
was
> thinking of a simple command line option (-extensible or something like
> that) to generate using it. This would apply to all the types, not the
> fine grain control you're suggesting below.
>
> > Also any thoughts about offering the
> > ability to INDIVIDUALLY flag/annotate specific schema types as
> > "extensible" to enable code-generation optimizations?
> It doesn't sound like a bad idea if people would find it useful. Adding
an
> annotation for this to the SDO spec would be harder since it's an
> implementation detail, but making it a Tuscany-specific extension
> shouldn't be a problem.
>
> >
> > - Ron
> >
> > ----- Original Message ----
> > From: Ron Gavlin <rg...@yahoo.com>
> > To: tuscany-user@ws.apache.org
> > Sent: Friday, June 30, 2006 4:58:26 PM
> > Subject: Re: DataObjectImpl.setEClass(EClass) throws
> > UnsupportedOperationException()
> >
> >
> > Frank,
> >
> > Thanks, that helped.
> >
> > I performed the following steps and the problem disappeared.
> >
> > 1. Added ExtensibleDataObject to the model (copied from
> DynamicDataObject)
> > 2. Re-generated code from model into a work area and applied updates
> > to relevant tuscany SDO classes [SDOFactory(Impl), SDOPackage(Impl)]
> > 3. Copied DynamicDataObjectImpl to ExtensibleDataObjectImpl
> > 4. Removed eStaticFeatureCount() method
> > 5. Modified ExtensibleDataObjectImpl eStaticClass() and FactoryImpl.
> > basicCreate to work with ExtensibleDataObjectImpls.
> > 6. Modified my "InfoTypeImpl" class to extend
> > ExtensibleDataObjectImpl instead of DataObjectImpl.
> > 7. Executed XMLHelper load test to ensure the data object loads
> > successfully using my mixed static/dynamic model...worked like a
champ.
> >
> > What option were you thinking of adding to the code generator to
> > trigger using this new base class? Along with this course-grained
> > approach, does it also make sense to offer the ability to
> > INDIVIDUALLY flag/annotate specific schema types as "extensible"? Is
> > there a significant performance/memory win using a DataObjectImpl
> > vs. ExtensibleDataObjectImpl?
> >
> > Thanks for all your help.
> >
> > - Ron
> >
> >
> >
> > ----- Original Message ----
> > From: Frank Budinsky <fr...@ca.ibm.com>
> > To: tuscany-user@ws.apache.org
> > Sent: Friday, June 30, 2006 2:17:58 PM
> > Subject: Re: DataObjectImpl.setEClass(EClass) throws
> > UnsupportedOperationException()
> >
> >
> > A little more background:
> >
> > In EMF:
> >
> > 1. BasicEObjectImpl is a base implementation of the EObject interface.
> It
> > doesn't allocate any storage - it expects subclasses to do that.
> > 2. EObjectImpl is the EMF default base class for generated classes. It
> is
> > a flexible implementation that allows the generated classes to be
> extended
> > by dynamic types.
> > 3. DynamicEObjectImpl extends EObjectImpl to optimize a few things for
> the
> > pure-dynamic case.
> > 4. EDataObjectImpl is a subclass of EObjectImpl that also implements
the
>
> > SDO DataObject interface - in Tuscany we don't have separate
> > implementation classes to implement the DataObject interface because
all
>
> > our implementation classes are for that purpose.
> >
> > in Tuscany:
> >
> > 1. DataObjectImpl is a subclass of EMF's BasicEObjectImpl that
> implements
> > the DataObject interface and allocates the absolute minimum storage.
> > Unlike EObjectImpl, which is an analous class for EMF (EObject's), it
is
>
> > not intended to be extended by dynamic types.
> > 2. DynamicDataObjectImpl is analogous to DynamicEObjectImpl in EMF,
but
> > for DataObjects.
> >
> > So, the ExtensibleDataObjectImpl class I've suggested is something
> between
> > DataObjectImpl and DynamicDataObjectImpl that would be the DataObject
> > equivalent of EObjectImpl.
> >
> > I hope this helps.
> > Frank.
> >
> > Ron Gavlin <rg...@yahoo.com> wrote on 06/30/2006 01:12:58 PM:
> >
> > > Frank,
> > >
> > > Does the proposed relationship between ExtensibleDataObjectImpl and
> > > DataObjectImpl somewhat mirror the relationship between EMF classes
> > > EObjectImpl and BasicEObjectImpl? At first glance, it appears
> > > EObjectImpl adds, amongst other things, support for this dynamic
> > > EClass. Would I look at the EMF/SDO 1.0 EDataObjectImpl class (which
> > > extends EObjectImpl) to get some ideas?
> > >
> > > - Ron
> > >
> > > ----- Original Message ----
> > > From: Ron Gavlin <rg...@yahoo.com>
> > > To: tuscany-user@ws.apache.org
> > > Sent: Friday, June 30, 2006 12:35:21 PM
> > > Subject: Re: DataObjectImpl.setEClass(EClass) throws
> > > UnsupportedOperationException()
> > >
> > >
> > > Hi Frank,
> > >
> > > I added JIRA feature request "TUSCANY-513" to track this issue.
> > > Unfortunately, I don't think I have the EMF experience required to
> > > whip-up such a class. Off the top of your head, do you have an idea
> > > what methods the class would probably need to implement to get the
job
>
> > done?
> > >
> > > - Ron
> > >
> > > ----- Original Message ----
> > > From: Frank Budinsky <fr...@ca.ibm.com>
> > > To: tuscany-user@ws.apache.org
> > > Sent: Friday, June 30, 2006 12:05:34 PM
> > > Subject: Re: DataObjectImpl.setEClass(EClass) throws
> > > UnsupportedOperationException()
> > >
> > >
> > > Hi Ron,
> > >
> > > Looking at this, it looks like the problem is that you're trying to
> > create
> > > dynamic subclasses of statically generated types. The bad news is
that
>
> > > Tuscany doesn't currently support that. The good news is that it's
not
>
> > too
> > > hard to add the support.
> > >
> > > The problem is that currently Tuscany only has these two primary
> > > DataObject implementation classes:
> > >
> > > 1. DataObjectImpl - is the base class used for statically generated
> > types.
> > > It is highly tuned for performance and footprint, so, unlike the
base
> > > class in SDO1 (actually EMF) it doesn't support dynamic extensions.
> > >
> > > 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs.
> It
> > is
> > > designed for pure dynamic types, not a mixture of static and
dynamic.
> > >
> > > To support what you want, we will need another base class, say
> > > ExtensibleDataObjectImpl, that is quite similar to
> > DynamicDataObjectImpl,
> > > but doesn't make the assumption that eStaticFeatureCount() is 0. My
> > guess
> > > is that there are only a few simple method overrides needed in this
> > class.
> > > Maybe you would like to try to prototype such a class yourself and
> hand
> > > modify your generated classes to extend from it? If you did that and
> > > tested it, you could submit a patch and we could then very quickly
add
> a
> >
> > > generator option to use it (maybe even make it the default). If
you'd
> > like
> > > to help with this, it would be very much appreciated!
> > >
> > > At any rate, you should probably open a JIRA feature request for
this.
> > >
> > > Thanks,
> > > Frank
> > >
> > > Ron Gavlin <rg...@yahoo.com> wrote on 06/30/2006 10:13:44 AM:
> > >
> > > > Frank,
> > > >
> > > > I am working with a mixed static/dynamic model similar to the one
> > > > listed at the bottom of this post. The http://example.org/ord
> > > > namespace is statically registered and has code-generated classes.
> The
> >
> > > > http://example.org/info/zipcode and http://example.org/info/street
> > > > namespaces are dynamically registered with no code-generated
> > > > classes. When I attempt to load the Sample Instance
(chapter04.xml),
> > > > I receive an UnsupportedOperationException thrown from
> > > > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the
> > > > exception is an instance of "InfoTypeImpl" from the "ord"
> > > > namespace/ePackage. The EClass parameter is "InfoType" from the
> > > > "zipcode" namespace. This instance document loads fine using
EMF/SDO
> > > > 1.0. Any suggestions I can try to work-around this problem?
> > > >
> > > > - Ron
> > > >
> > > >
> > > > Sample Instance (chapter04.xml)
> > > > <ord:order xmlns:ord="<http://example.org/ord>";;;;;
> > > > xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>";;;;;
> > > > xsi:schemaLocation="<http://example.org/ord> chapter04ord1.xsd">
> > > > <ord:number>123ABBCC123</ord:number>
> > > > <ord:customer>
> > > > <ord:name>Pat Walmsley</ord:name>
> > > > <ord:number>15465</ord:number>
> > > > <info xsi:type="ns1:InfoType" xmlns=""
> > > > xmlns:ns1="<http://example.org/info/zipcode>";;;;;>
> > > > <zipcode>21043</zipcode>
> > > > </info>
> > > > </ord:customer>
> > > > <ord:customer>
> > > > <ord:name>Priscilla Walmsley</ord:name>
> > > > <ord:number>15466</ord:number>
> > > > <info xsi:type="ns1:InfoType" xmlns=""
> > > > xmlns:ns1="<http://example.org/info/street>";;;;;>
> > > > <street>341 Duckworth Way</street>
> > > > </info>
> > > > </ord:customer>
> > > > <ord:items>
> > > > <product>
> > > > <number>557</number>
> > > > <name>Short-Sleeved Linen Blouse</name>
> > > > <size system="US-DRESS">10</size>
> > > > <color value="blue"/>
> > > > </product>
> > > > </ord:items>
> > > > </ord:order>
> > > > Schema Document 1 (chapter04ord1.xsd)
> > > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;;
> > > > targetNamespace="<http://example.org/ord>";;;;;;
> > > > xmlns="<http://example.org/ord>";;;;;;
> > > > xmlns:prod="<http://example.org/prod>";;;;;;
> > > > elementFormDefault="qualified">
> > > > <xsd:import namespace="<http://example.org/prod>";;;;;;
> > > > schemaLocation="chapter04prod.xsd"/>
> > > > <xsd:simpleType name="OrderNumType">
> > > > <xsd:restriction base="xsd:string"/>
> > > > </xsd:simpleType>
> > > > <xsd:complexType name="InfoType"/>
> > > > <xsd:complexType name="CustomerType">
> > > > <xsd:sequence>
> > > > <xsd:element name="name" type="CustNameType"/>
> > > > <xsd:element name="number" type="xsd:integer"/>
> > > > <xsd:element name="info" type="InfoType" form="unqualified"/>
> > > > </xsd:sequence>
> > > > </xsd:complexType>
> > > > <xsd:simpleType name="CustNameType">
> > > > <xsd:restriction base="xsd:string"/>
> > > > </xsd:simpleType>
> > > > <xsd:element name="order" type="OrderType"/>
> > > > <xsd:complexType name="OrderType">
> > > > <xsd:sequence>
> > > > <xsd:element name="number" type="OrderNumType"/>
> > > > <xsd:element name="customer" type="CustomerType"
> > > > maxOccurs="unbounded"/>
> > > > <xsd:element name="items" type="prod:ItemsType"/>
> > > > </xsd:sequence>
> > > > </xsd:complexType>
> > > > </xsd:schema>
> > > > Schema Document 2 (chapter04infozipcode.xsd)
> > > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;;
> > > > xmlns:ord="<http://example.org/ord>";;;;;;
> > > > xmlns="<http://example.org/info/zipcode>";;;;;;
> > > > targetNamespace="<http://example.org/info/zipcode>";;;;;;
> > > > elementFormDefault="unqualified">
> > > > <xsd:import namespace="<http://example.org/ord>";;;;;;
> > > > schemaLocation="chapter04ord1.xsd"/>
> > > > <xsd:complexType name="InfoType">
> > > > <xsd:complexContent>
> > > > <xsd:extension base="ord:InfoType">
> > > > <xsd:sequence>
> > > > <xsd:element name="zipcode" type="xsd:string"/>
> > > > </xsd:sequence>
> > > > </xsd:extension>
> > > > </xsd:complexContent>
> > > > </xsd:complexType>
> > > > </xsd:schema>
> > > > Schema Document 3 (chapter04infostreet.xsd)
> > > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;;
> > > > xmlns:ord="<http://example.org/ord>";;;;;;
> > > > xmlns="<http://example.org/info/street>";;;;;;
> > > > targetNamespace="<http://example.org/info/street>";;;;;;
> > > > elementFormDefault="unqualified">
> > > > <xsd:import namespace="<http://example.org/ord>";;;;;;
> > > > schemaLocation="chapter04ord1.xsd"/>
> > > > <xsd:complexType name="InfoType">
> > > > <xsd:complexContent>
> > > > <xsd:extension base="ord:InfoType">
> > > > <xsd:sequence>
> > > > <xsd:element name="street" type="xsd:string"/>
> > > > </xsd:sequence>
> > > > </xsd:extension>
> > > > </xsd:complexContent>
> > > > </xsd:complexType>
> > > > </xsd:schema>
> > > > Schema Document 4 (chapter04prod.xsd)
> > > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;;
> > > > xmlns="<http://example.org/prod>";;;;;;
> > > > targetNamespace="<http://example.org/prod>";;;;;;
> > > > elementFormDefault="unqualified">
> > > > <xsd:complexType name="ItemsType">
> > > > <xsd:sequence>
> > > > <xsd:element name="product" type="ProductType"/>
> > > > </xsd:sequence>
> > > > </xsd:complexType>
> > > > <xsd:complexType name="ProductType">
> > > > <xsd:sequence>
> > > > <xsd:element name="number" type="xsd:integer"/>
> > > > <xsd:element name="name" type="xsd:string"/>
> > > > <xsd:element name="size" type="SizeType"/>
> > > > <xsd:element name="color" type="ColorType"/>
> > > > </xsd:sequence>
> > > > </xsd:complexType>
> > > > <xsd:complexType name="SizeType">
> > > > <xsd:simpleContent>
> > > > <xsd:extension base="xsd:integer">
> > > > <xsd:attribute name="system" type="xsd:string"/>
> > > > </xsd:extension>
> > > > </xsd:simpleContent>
> > > > </xsd:complexType>
> > > > <xsd:complexType name="ColorType">
> > > > <xsd:attribute name="value" type="xsd:string"/>
> > > > </xsd:complexType>
> > > > </xsd:schema>
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException()
Posted by Ron Gavlin <rg...@yahoo.com>.
What do you think about making "extensible" the default behavior and adding an option "OPTION_NOT_EXTENSIBLE" or "OPTION_NO_EXTENSION" for those folks that don't want the "extensible" overhead?
----- Original Message ----
From: Frank Budinsky <fr...@ca.ibm.com>
To: tuscany-user@ws.apache.org
Cc: tuscany-user@ws.apache.org
Sent: Wednesday, July 5, 2006 12:06:45 PM
Subject: Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException()
Ron Gavlin <rg...@yahoo.com> wrote on 07/05/2006 10:09:51 AM:
> Greetings,
>
> In order to support mixed static/dynamic models, I made changes to
> SDOXSDEcoreBuilder as well as the changes listed in my previous
> message. I'm investigating whether I can contribute these back to
> the community. I'll let you know when I have more information.
That would be great if you can. If so, open a JIRA for the issue and
attach a patch.
> The changes made to SDOXSDEcoreBuilder could just as easily have been
> applied to EMF's EcoreBuilder. I think EMF itself would probably
> benefit from this mixed-model support.
Since you haven't said exactly what your change to SDOXSDEcoreBuilder
actually does, I can't really comment on whether or not it would be a good
addition to EMF itself. If it's some kind of annotation to choose on a
per-complexType basis whether to support a mixed dynamic/static base
class, I think that since EMF currently has no static-only optimized base
class, I'm not sure they'd want it there ... but you might want to suggest
it on the EMF newsgroup to let them comment.
>
> Do you have any thoughts about modifying the code generator to
> support this new base class?
Once we have the ExtensibleDataObjectImpl base class available, then I was
thinking of a simple command line option (-extensible or something like
that) to generate using it. This would apply to all the types, not the
fine grain control you're suggesting below.
> Also any thoughts about offering the
> ability to INDIVIDUALLY flag/annotate specific schema types as
> "extensible" to enable code-generation optimizations?
It doesn't sound like a bad idea if people would find it useful. Adding an
annotation for this to the SDO spec would be harder since it's an
implementation detail, but making it a Tuscany-specific extension
shouldn't be a problem.
>
> - Ron
>
> ----- Original Message ----
> From: Ron Gavlin <rg...@yahoo.com>
> To: tuscany-user@ws.apache.org
> Sent: Friday, June 30, 2006 4:58:26 PM
> Subject: Re: DataObjectImpl.setEClass(EClass) throws
> UnsupportedOperationException()
>
>
> Frank,
>
> Thanks, that helped.
>
> I performed the following steps and the problem disappeared.
>
> 1. Added ExtensibleDataObject to the model (copied from
DynamicDataObject)
> 2. Re-generated code from model into a work area and applied updates
> to relevant tuscany SDO classes [SDOFactory(Impl), SDOPackage(Impl)]
> 3. Copied DynamicDataObjectImpl to ExtensibleDataObjectImpl
> 4. Removed eStaticFeatureCount() method
> 5. Modified ExtensibleDataObjectImpl eStaticClass() and FactoryImpl.
> basicCreate to work with ExtensibleDataObjectImpls.
> 6. Modified my "InfoTypeImpl" class to extend
> ExtensibleDataObjectImpl instead of DataObjectImpl.
> 7. Executed XMLHelper load test to ensure the data object loads
> successfully using my mixed static/dynamic model...worked like a champ.
>
> What option were you thinking of adding to the code generator to
> trigger using this new base class? Along with this course-grained
> approach, does it also make sense to offer the ability to
> INDIVIDUALLY flag/annotate specific schema types as "extensible"? Is
> there a significant performance/memory win using a DataObjectImpl
> vs. ExtensibleDataObjectImpl?
>
> Thanks for all your help.
>
> - Ron
>
>
>
> ----- Original Message ----
> From: Frank Budinsky <fr...@ca.ibm.com>
> To: tuscany-user@ws.apache.org
> Sent: Friday, June 30, 2006 2:17:58 PM
> Subject: Re: DataObjectImpl.setEClass(EClass) throws
> UnsupportedOperationException()
>
>
> A little more background:
>
> In EMF:
>
> 1. BasicEObjectImpl is a base implementation of the EObject interface.
It
> doesn't allocate any storage - it expects subclasses to do that.
> 2. EObjectImpl is the EMF default base class for generated classes. It
is
> a flexible implementation that allows the generated classes to be
extended
> by dynamic types.
> 3. DynamicEObjectImpl extends EObjectImpl to optimize a few things for
the
> pure-dynamic case.
> 4. EDataObjectImpl is a subclass of EObjectImpl that also implements the
> SDO DataObject interface - in Tuscany we don't have separate
> implementation classes to implement the DataObject interface because all
> our implementation classes are for that purpose.
>
> in Tuscany:
>
> 1. DataObjectImpl is a subclass of EMF's BasicEObjectImpl that
implements
> the DataObject interface and allocates the absolute minimum storage.
> Unlike EObjectImpl, which is an analous class for EMF (EObject's), it is
> not intended to be extended by dynamic types.
> 2. DynamicDataObjectImpl is analogous to DynamicEObjectImpl in EMF, but
> for DataObjects.
>
> So, the ExtensibleDataObjectImpl class I've suggested is something
between
> DataObjectImpl and DynamicDataObjectImpl that would be the DataObject
> equivalent of EObjectImpl.
>
> I hope this helps.
> Frank.
>
> Ron Gavlin <rg...@yahoo.com> wrote on 06/30/2006 01:12:58 PM:
>
> > Frank,
> >
> > Does the proposed relationship between ExtensibleDataObjectImpl and
> > DataObjectImpl somewhat mirror the relationship between EMF classes
> > EObjectImpl and BasicEObjectImpl? At first glance, it appears
> > EObjectImpl adds, amongst other things, support for this dynamic
> > EClass. Would I look at the EMF/SDO 1.0 EDataObjectImpl class (which
> > extends EObjectImpl) to get some ideas?
> >
> > - Ron
> >
> > ----- Original Message ----
> > From: Ron Gavlin <rg...@yahoo.com>
> > To: tuscany-user@ws.apache.org
> > Sent: Friday, June 30, 2006 12:35:21 PM
> > Subject: Re: DataObjectImpl.setEClass(EClass) throws
> > UnsupportedOperationException()
> >
> >
> > Hi Frank,
> >
> > I added JIRA feature request "TUSCANY-513" to track this issue.
> > Unfortunately, I don't think I have the EMF experience required to
> > whip-up such a class. Off the top of your head, do you have an idea
> > what methods the class would probably need to implement to get the job
> done?
> >
> > - Ron
> >
> > ----- Original Message ----
> > From: Frank Budinsky <fr...@ca.ibm.com>
> > To: tuscany-user@ws.apache.org
> > Sent: Friday, June 30, 2006 12:05:34 PM
> > Subject: Re: DataObjectImpl.setEClass(EClass) throws
> > UnsupportedOperationException()
> >
> >
> > Hi Ron,
> >
> > Looking at this, it looks like the problem is that you're trying to
> create
> > dynamic subclasses of statically generated types. The bad news is that
> > Tuscany doesn't currently support that. The good news is that it's not
> too
> > hard to add the support.
> >
> > The problem is that currently Tuscany only has these two primary
> > DataObject implementation classes:
> >
> > 1. DataObjectImpl - is the base class used for statically generated
> types.
> > It is highly tuned for performance and footprint, so, unlike the base
> > class in SDO1 (actually EMF) it doesn't support dynamic extensions.
> >
> > 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs.
It
> is
> > designed for pure dynamic types, not a mixture of static and dynamic.
> >
> > To support what you want, we will need another base class, say
> > ExtensibleDataObjectImpl, that is quite similar to
> DynamicDataObjectImpl,
> > but doesn't make the assumption that eStaticFeatureCount() is 0. My
> guess
> > is that there are only a few simple method overrides needed in this
> class.
> > Maybe you would like to try to prototype such a class yourself and
hand
> > modify your generated classes to extend from it? If you did that and
> > tested it, you could submit a patch and we could then very quickly add
a
>
> > generator option to use it (maybe even make it the default). If you'd
> like
> > to help with this, it would be very much appreciated!
> >
> > At any rate, you should probably open a JIRA feature request for this.
> >
> > Thanks,
> > Frank
> >
> > Ron Gavlin <rg...@yahoo.com> wrote on 06/30/2006 10:13:44 AM:
> >
> > > Frank,
> > >
> > > I am working with a mixed static/dynamic model similar to the one
> > > listed at the bottom of this post. The http://example.org/ord
> > > namespace is statically registered and has code-generated classes.
The
>
> > > http://example.org/info/zipcode and http://example.org/info/street
> > > namespaces are dynamically registered with no code-generated
> > > classes. When I attempt to load the Sample Instance (chapter04.xml),
> > > I receive an UnsupportedOperationException thrown from
> > > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the
> > > exception is an instance of "InfoTypeImpl" from the "ord"
> > > namespace/ePackage. The EClass parameter is "InfoType" from the
> > > "zipcode" namespace. This instance document loads fine using EMF/SDO
> > > 1.0. Any suggestions I can try to work-around this problem?
> > >
> > > - Ron
> > >
> > >
> > > Sample Instance (chapter04.xml)
> > > <ord:order xmlns:ord="<http://example.org/ord>";;;;;
> > > xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>";;;;;
> > > xsi:schemaLocation="<http://example.org/ord> chapter04ord1.xsd">
> > > <ord:number>123ABBCC123</ord:number>
> > > <ord:customer>
> > > <ord:name>Pat Walmsley</ord:name>
> > > <ord:number>15465</ord:number>
> > > <info xsi:type="ns1:InfoType" xmlns=""
> > > xmlns:ns1="<http://example.org/info/zipcode>";;;;;>
> > > <zipcode>21043</zipcode>
> > > </info>
> > > </ord:customer>
> > > <ord:customer>
> > > <ord:name>Priscilla Walmsley</ord:name>
> > > <ord:number>15466</ord:number>
> > > <info xsi:type="ns1:InfoType" xmlns=""
> > > xmlns:ns1="<http://example.org/info/street>";;;;;>
> > > <street>341 Duckworth Way</street>
> > > </info>
> > > </ord:customer>
> > > <ord:items>
> > > <product>
> > > <number>557</number>
> > > <name>Short-Sleeved Linen Blouse</name>
> > > <size system="US-DRESS">10</size>
> > > <color value="blue"/>
> > > </product>
> > > </ord:items>
> > > </ord:order>
> > > Schema Document 1 (chapter04ord1.xsd)
> > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;;
> > > targetNamespace="<http://example.org/ord>";;;;;;
> > > xmlns="<http://example.org/ord>";;;;;;
> > > xmlns:prod="<http://example.org/prod>";;;;;;
> > > elementFormDefault="qualified">
> > > <xsd:import namespace="<http://example.org/prod>";;;;;;
> > > schemaLocation="chapter04prod.xsd"/>
> > > <xsd:simpleType name="OrderNumType">
> > > <xsd:restriction base="xsd:string"/>
> > > </xsd:simpleType>
> > > <xsd:complexType name="InfoType"/>
> > > <xsd:complexType name="CustomerType">
> > > <xsd:sequence>
> > > <xsd:element name="name" type="CustNameType"/>
> > > <xsd:element name="number" type="xsd:integer"/>
> > > <xsd:element name="info" type="InfoType" form="unqualified"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > <xsd:simpleType name="CustNameType">
> > > <xsd:restriction base="xsd:string"/>
> > > </xsd:simpleType>
> > > <xsd:element name="order" type="OrderType"/>
> > > <xsd:complexType name="OrderType">
> > > <xsd:sequence>
> > > <xsd:element name="number" type="OrderNumType"/>
> > > <xsd:element name="customer" type="CustomerType"
> > > maxOccurs="unbounded"/>
> > > <xsd:element name="items" type="prod:ItemsType"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > </xsd:schema>
> > > Schema Document 2 (chapter04infozipcode.xsd)
> > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;;
> > > xmlns:ord="<http://example.org/ord>";;;;;;
> > > xmlns="<http://example.org/info/zipcode>";;;;;;
> > > targetNamespace="<http://example.org/info/zipcode>";;;;;;
> > > elementFormDefault="unqualified">
> > > <xsd:import namespace="<http://example.org/ord>";;;;;;
> > > schemaLocation="chapter04ord1.xsd"/>
> > > <xsd:complexType name="InfoType">
> > > <xsd:complexContent>
> > > <xsd:extension base="ord:InfoType">
> > > <xsd:sequence>
> > > <xsd:element name="zipcode" type="xsd:string"/>
> > > </xsd:sequence>
> > > </xsd:extension>
> > > </xsd:complexContent>
> > > </xsd:complexType>
> > > </xsd:schema>
> > > Schema Document 3 (chapter04infostreet.xsd)
> > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;;
> > > xmlns:ord="<http://example.org/ord>";;;;;;
> > > xmlns="<http://example.org/info/street>";;;;;;
> > > targetNamespace="<http://example.org/info/street>";;;;;;
> > > elementFormDefault="unqualified">
> > > <xsd:import namespace="<http://example.org/ord>";;;;;;
> > > schemaLocation="chapter04ord1.xsd"/>
> > > <xsd:complexType name="InfoType">
> > > <xsd:complexContent>
> > > <xsd:extension base="ord:InfoType">
> > > <xsd:sequence>
> > > <xsd:element name="street" type="xsd:string"/>
> > > </xsd:sequence>
> > > </xsd:extension>
> > > </xsd:complexContent>
> > > </xsd:complexType>
> > > </xsd:schema>
> > > Schema Document 4 (chapter04prod.xsd)
> > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;;
> > > xmlns="<http://example.org/prod>";;;;;;
> > > targetNamespace="<http://example.org/prod>";;;;;;
> > > elementFormDefault="unqualified">
> > > <xsd:complexType name="ItemsType">
> > > <xsd:sequence>
> > > <xsd:element name="product" type="ProductType"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > <xsd:complexType name="ProductType">
> > > <xsd:sequence>
> > > <xsd:element name="number" type="xsd:integer"/>
> > > <xsd:element name="name" type="xsd:string"/>
> > > <xsd:element name="size" type="SizeType"/>
> > > <xsd:element name="color" type="ColorType"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > <xsd:complexType name="SizeType">
> > > <xsd:simpleContent>
> > > <xsd:extension base="xsd:integer">
> > > <xsd:attribute name="system" type="xsd:string"/>
> > > </xsd:extension>
> > > </xsd:simpleContent>
> > > </xsd:complexType>
> > > <xsd:complexType name="ColorType">
> > > <xsd:attribute name="value" type="xsd:string"/>
> > > </xsd:complexType>
> > > </xsd:schema>
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException()
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Ron Gavlin <rg...@yahoo.com> wrote on 07/05/2006 10:09:51 AM:
> Greetings,
>
> In order to support mixed static/dynamic models, I made changes to
> SDOXSDEcoreBuilder as well as the changes listed in my previous
> message. I'm investigating whether I can contribute these back to
> the community. I'll let you know when I have more information.
That would be great if you can. If so, open a JIRA for the issue and
attach a patch.
> The changes made to SDOXSDEcoreBuilder could just as easily have been
> applied to EMF's EcoreBuilder. I think EMF itself would probably
> benefit from this mixed-model support.
Since you haven't said exactly what your change to SDOXSDEcoreBuilder
actually does, I can't really comment on whether or not it would be a good
addition to EMF itself. If it's some kind of annotation to choose on a
per-complexType basis whether to support a mixed dynamic/static base
class, I think that since EMF currently has no static-only optimized base
class, I'm not sure they'd want it there ... but you might want to suggest
it on the EMF newsgroup to let them comment.
>
> Do you have any thoughts about modifying the code generator to
> support this new base class?
Once we have the ExtensibleDataObjectImpl base class available, then I was
thinking of a simple command line option (-extensible or something like
that) to generate using it. This would apply to all the types, not the
fine grain control you're suggesting below.
> Also any thoughts about offering the
> ability to INDIVIDUALLY flag/annotate specific schema types as
> "extensible" to enable code-generation optimizations?
It doesn't sound like a bad idea if people would find it useful. Adding an
annotation for this to the SDO spec would be harder since it's an
implementation detail, but making it a Tuscany-specific extension
shouldn't be a problem.
>
> - Ron
>
> ----- Original Message ----
> From: Ron Gavlin <rg...@yahoo.com>
> To: tuscany-user@ws.apache.org
> Sent: Friday, June 30, 2006 4:58:26 PM
> Subject: Re: DataObjectImpl.setEClass(EClass) throws
> UnsupportedOperationException()
>
>
> Frank,
>
> Thanks, that helped.
>
> I performed the following steps and the problem disappeared.
>
> 1. Added ExtensibleDataObject to the model (copied from
DynamicDataObject)
> 2. Re-generated code from model into a work area and applied updates
> to relevant tuscany SDO classes [SDOFactory(Impl), SDOPackage(Impl)]
> 3. Copied DynamicDataObjectImpl to ExtensibleDataObjectImpl
> 4. Removed eStaticFeatureCount() method
> 5. Modified ExtensibleDataObjectImpl eStaticClass() and FactoryImpl.
> basicCreate to work with ExtensibleDataObjectImpls.
> 6. Modified my "InfoTypeImpl" class to extend
> ExtensibleDataObjectImpl instead of DataObjectImpl.
> 7. Executed XMLHelper load test to ensure the data object loads
> successfully using my mixed static/dynamic model...worked like a champ.
>
> What option were you thinking of adding to the code generator to
> trigger using this new base class? Along with this course-grained
> approach, does it also make sense to offer the ability to
> INDIVIDUALLY flag/annotate specific schema types as "extensible"? Is
> there a significant performance/memory win using a DataObjectImpl
> vs. ExtensibleDataObjectImpl?
>
> Thanks for all your help.
>
> - Ron
>
>
>
> ----- Original Message ----
> From: Frank Budinsky <fr...@ca.ibm.com>
> To: tuscany-user@ws.apache.org
> Sent: Friday, June 30, 2006 2:17:58 PM
> Subject: Re: DataObjectImpl.setEClass(EClass) throws
> UnsupportedOperationException()
>
>
> A little more background:
>
> In EMF:
>
> 1. BasicEObjectImpl is a base implementation of the EObject interface.
It
> doesn't allocate any storage - it expects subclasses to do that.
> 2. EObjectImpl is the EMF default base class for generated classes. It
is
> a flexible implementation that allows the generated classes to be
extended
> by dynamic types.
> 3. DynamicEObjectImpl extends EObjectImpl to optimize a few things for
the
> pure-dynamic case.
> 4. EDataObjectImpl is a subclass of EObjectImpl that also implements the
> SDO DataObject interface - in Tuscany we don't have separate
> implementation classes to implement the DataObject interface because all
> our implementation classes are for that purpose.
>
> in Tuscany:
>
> 1. DataObjectImpl is a subclass of EMF's BasicEObjectImpl that
implements
> the DataObject interface and allocates the absolute minimum storage.
> Unlike EObjectImpl, which is an analous class for EMF (EObject's), it is
> not intended to be extended by dynamic types.
> 2. DynamicDataObjectImpl is analogous to DynamicEObjectImpl in EMF, but
> for DataObjects.
>
> So, the ExtensibleDataObjectImpl class I've suggested is something
between
> DataObjectImpl and DynamicDataObjectImpl that would be the DataObject
> equivalent of EObjectImpl.
>
> I hope this helps.
> Frank.
>
> Ron Gavlin <rg...@yahoo.com> wrote on 06/30/2006 01:12:58 PM:
>
> > Frank,
> >
> > Does the proposed relationship between ExtensibleDataObjectImpl and
> > DataObjectImpl somewhat mirror the relationship between EMF classes
> > EObjectImpl and BasicEObjectImpl? At first glance, it appears
> > EObjectImpl adds, amongst other things, support for this dynamic
> > EClass. Would I look at the EMF/SDO 1.0 EDataObjectImpl class (which
> > extends EObjectImpl) to get some ideas?
> >
> > - Ron
> >
> > ----- Original Message ----
> > From: Ron Gavlin <rg...@yahoo.com>
> > To: tuscany-user@ws.apache.org
> > Sent: Friday, June 30, 2006 12:35:21 PM
> > Subject: Re: DataObjectImpl.setEClass(EClass) throws
> > UnsupportedOperationException()
> >
> >
> > Hi Frank,
> >
> > I added JIRA feature request "TUSCANY-513" to track this issue.
> > Unfortunately, I don't think I have the EMF experience required to
> > whip-up such a class. Off the top of your head, do you have an idea
> > what methods the class would probably need to implement to get the job
> done?
> >
> > - Ron
> >
> > ----- Original Message ----
> > From: Frank Budinsky <fr...@ca.ibm.com>
> > To: tuscany-user@ws.apache.org
> > Sent: Friday, June 30, 2006 12:05:34 PM
> > Subject: Re: DataObjectImpl.setEClass(EClass) throws
> > UnsupportedOperationException()
> >
> >
> > Hi Ron,
> >
> > Looking at this, it looks like the problem is that you're trying to
> create
> > dynamic subclasses of statically generated types. The bad news is that
> > Tuscany doesn't currently support that. The good news is that it's not
> too
> > hard to add the support.
> >
> > The problem is that currently Tuscany only has these two primary
> > DataObject implementation classes:
> >
> > 1. DataObjectImpl - is the base class used for statically generated
> types.
> > It is highly tuned for performance and footprint, so, unlike the base
> > class in SDO1 (actually EMF) it doesn't support dynamic extensions.
> >
> > 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs.
It
> is
> > designed for pure dynamic types, not a mixture of static and dynamic.
> >
> > To support what you want, we will need another base class, say
> > ExtensibleDataObjectImpl, that is quite similar to
> DynamicDataObjectImpl,
> > but doesn't make the assumption that eStaticFeatureCount() is 0. My
> guess
> > is that there are only a few simple method overrides needed in this
> class.
> > Maybe you would like to try to prototype such a class yourself and
hand
> > modify your generated classes to extend from it? If you did that and
> > tested it, you could submit a patch and we could then very quickly add
a
>
> > generator option to use it (maybe even make it the default). If you'd
> like
> > to help with this, it would be very much appreciated!
> >
> > At any rate, you should probably open a JIRA feature request for this.
> >
> > Thanks,
> > Frank
> >
> > Ron Gavlin <rg...@yahoo.com> wrote on 06/30/2006 10:13:44 AM:
> >
> > > Frank,
> > >
> > > I am working with a mixed static/dynamic model similar to the one
> > > listed at the bottom of this post. The http://example.org/ord
> > > namespace is statically registered and has code-generated classes.
The
>
> > > http://example.org/info/zipcode and http://example.org/info/street
> > > namespaces are dynamically registered with no code-generated
> > > classes. When I attempt to load the Sample Instance (chapter04.xml),
> > > I receive an UnsupportedOperationException thrown from
> > > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the
> > > exception is an instance of "InfoTypeImpl" from the "ord"
> > > namespace/ePackage. The EClass parameter is "InfoType" from the
> > > "zipcode" namespace. This instance document loads fine using EMF/SDO
> > > 1.0. Any suggestions I can try to work-around this problem?
> > >
> > > - Ron
> > >
> > >
> > > Sample Instance (chapter04.xml)
> > > <ord:order xmlns:ord="<http://example.org/ord>";;;;
> > > xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>";;;;
> > > xsi:schemaLocation="<http://example.org/ord> chapter04ord1.xsd">
> > > <ord:number>123ABBCC123</ord:number>
> > > <ord:customer>
> > > <ord:name>Pat Walmsley</ord:name>
> > > <ord:number>15465</ord:number>
> > > <info xsi:type="ns1:InfoType" xmlns=""
> > > xmlns:ns1="<http://example.org/info/zipcode>";;;;>
> > > <zipcode>21043</zipcode>
> > > </info>
> > > </ord:customer>
> > > <ord:customer>
> > > <ord:name>Priscilla Walmsley</ord:name>
> > > <ord:number>15466</ord:number>
> > > <info xsi:type="ns1:InfoType" xmlns=""
> > > xmlns:ns1="<http://example.org/info/street>";;;;>
> > > <street>341 Duckworth Way</street>
> > > </info>
> > > </ord:customer>
> > > <ord:items>
> > > <product>
> > > <number>557</number>
> > > <name>Short-Sleeved Linen Blouse</name>
> > > <size system="US-DRESS">10</size>
> > > <color value="blue"/>
> > > </product>
> > > </ord:items>
> > > </ord:order>
> > > Schema Document 1 (chapter04ord1.xsd)
> > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;
> > > targetNamespace="<http://example.org/ord>";;;;;
> > > xmlns="<http://example.org/ord>";;;;;
> > > xmlns:prod="<http://example.org/prod>";;;;;
> > > elementFormDefault="qualified">
> > > <xsd:import namespace="<http://example.org/prod>";;;;;
> > > schemaLocation="chapter04prod.xsd"/>
> > > <xsd:simpleType name="OrderNumType">
> > > <xsd:restriction base="xsd:string"/>
> > > </xsd:simpleType>
> > > <xsd:complexType name="InfoType"/>
> > > <xsd:complexType name="CustomerType">
> > > <xsd:sequence>
> > > <xsd:element name="name" type="CustNameType"/>
> > > <xsd:element name="number" type="xsd:integer"/>
> > > <xsd:element name="info" type="InfoType" form="unqualified"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > <xsd:simpleType name="CustNameType">
> > > <xsd:restriction base="xsd:string"/>
> > > </xsd:simpleType>
> > > <xsd:element name="order" type="OrderType"/>
> > > <xsd:complexType name="OrderType">
> > > <xsd:sequence>
> > > <xsd:element name="number" type="OrderNumType"/>
> > > <xsd:element name="customer" type="CustomerType"
> > > maxOccurs="unbounded"/>
> > > <xsd:element name="items" type="prod:ItemsType"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > </xsd:schema>
> > > Schema Document 2 (chapter04infozipcode.xsd)
> > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;
> > > xmlns:ord="<http://example.org/ord>";;;;;
> > > xmlns="<http://example.org/info/zipcode>";;;;;
> > > targetNamespace="<http://example.org/info/zipcode>";;;;;
> > > elementFormDefault="unqualified">
> > > <xsd:import namespace="<http://example.org/ord>";;;;;
> > > schemaLocation="chapter04ord1.xsd"/>
> > > <xsd:complexType name="InfoType">
> > > <xsd:complexContent>
> > > <xsd:extension base="ord:InfoType">
> > > <xsd:sequence>
> > > <xsd:element name="zipcode" type="xsd:string"/>
> > > </xsd:sequence>
> > > </xsd:extension>
> > > </xsd:complexContent>
> > > </xsd:complexType>
> > > </xsd:schema>
> > > Schema Document 3 (chapter04infostreet.xsd)
> > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;
> > > xmlns:ord="<http://example.org/ord>";;;;;
> > > xmlns="<http://example.org/info/street>";;;;;
> > > targetNamespace="<http://example.org/info/street>";;;;;
> > > elementFormDefault="unqualified">
> > > <xsd:import namespace="<http://example.org/ord>";;;;;
> > > schemaLocation="chapter04ord1.xsd"/>
> > > <xsd:complexType name="InfoType">
> > > <xsd:complexContent>
> > > <xsd:extension base="ord:InfoType">
> > > <xsd:sequence>
> > > <xsd:element name="street" type="xsd:string"/>
> > > </xsd:sequence>
> > > </xsd:extension>
> > > </xsd:complexContent>
> > > </xsd:complexType>
> > > </xsd:schema>
> > > Schema Document 4 (chapter04prod.xsd)
> > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;
> > > xmlns="<http://example.org/prod>";;;;;
> > > targetNamespace="<http://example.org/prod>";;;;;
> > > elementFormDefault="unqualified">
> > > <xsd:complexType name="ItemsType">
> > > <xsd:sequence>
> > > <xsd:element name="product" type="ProductType"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > <xsd:complexType name="ProductType">
> > > <xsd:sequence>
> > > <xsd:element name="number" type="xsd:integer"/>
> > > <xsd:element name="name" type="xsd:string"/>
> > > <xsd:element name="size" type="SizeType"/>
> > > <xsd:element name="color" type="ColorType"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > <xsd:complexType name="SizeType">
> > > <xsd:simpleContent>
> > > <xsd:extension base="xsd:integer">
> > > <xsd:attribute name="system" type="xsd:string"/>
> > > </xsd:extension>
> > > </xsd:simpleContent>
> > > </xsd:complexType>
> > > <xsd:complexType name="ColorType">
> > > <xsd:attribute name="value" type="xsd:string"/>
> > > </xsd:complexType>
> > > </xsd:schema>
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org