[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504205 ] Ron Gavlin commented on TUSCANY-513: Folks, I have attached version 2 of the patch for this issue. It includes the test harness that I accidentally left out of the previous patch. Since the patch includes changes that affect code-generated classes, I regenerated most of those classes, except for the classes generated by the ModelFactory. I applied the changes by hand to those classes. Please let me know if you have questions. Your timely feedback and subsequent application of the patch is appreciated. Regards, - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.2.patch, tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.2.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
Re: [jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
Ron, I'm looking at this right now. Kelvin. On 13/06/07, Ron Gavlin (JIRA) tuscany-dev@ws.apache.org wrote: [ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504205] Ron Gavlin commented on TUSCANY-513: Folks, I have attached version 2 of the patch for this issue. It includes the test harness that I accidentally left out of the previous patch. Since the patch includes changes that affect code-generated classes, I regenerated most of those classes, except for the classes generated by the ModelFactory. I applied the changes by hand to those classes. Please let me know if you have questions. Your timely feedback and subsequent application of the patch is appreciated. Regards, - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.2.patch, tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.2.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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;;
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504252 ] Kelvin Goodson commented on TUSCANY-513: Fixed in commit 546884. Thanks for taking the trouble to produce a nice clean patch Ron. Apart from all the functional stuff it was great that the licenses were all in place, the new test case was hooked up into AllTests, the model files were updated, the test data organisation was good; I really appreciate this. Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.2.patch, tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.2.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504263 ] Ron Gavlin commented on TUSCANY-513: Kelvin, My pleasure. Thanks for reviewing and applying this patch so quickly. Regards, - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.2.patch, tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.2.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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/
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503403 ] Ron Gavlin commented on TUSCANY-513: It appears I need to re-generate at least the sdo model classes such as ...sdo.model.impl.TypeImpl in order for the new public Type getStaticType() method to be added to these classes, correct? I also need to re-generate many of the test SDO code-generated classes. Are the XSD2JavaGenerator invocations required to re-generate all these classes documented anywhere? Would it make sense to have utility methods available somewhere to help with this activity? Thanks in advance, - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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/
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503411 ] Ron Gavlin commented on TUSCANY-513: After further investigation, it appears all tests complete successfully after renaming the getType() to getStaticType() method within the TypeImpl and PropertyImpl classes. As part of this patch, do you recommend that these changes be manually applied to these two classes or should all model classes be regenerated? Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503419 ] Ron Gavlin commented on TUSCANY-513: I have been unable to find the schema used to generate factory class tuscany-sdo-tools/src/test/java/com/example/customer/impl/CustomerFactoryImpl.java. Does one exist or should I manually modify the generated classes by hand? - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503452 ] Kelvin Goodson commented on TUSCANY-513: Hi Ron, only just seen your comments. The xsd for the Customer class is CustomerAccount.xsd I think in the tools project src/test/resources folder. This is highlighting the fact that we don't have a good story on exercising/testing the tools project, in that if we did, all these things would be regenerated every time we did a maven build. I added some code to the generator so that, tucked away inside the FactoryImpl class is a record of the arguments (that I could lay my hands on) which were used for the generation of the set of classes. For example, I see by that means that the generation of the CustomerAccounts class used a specific -prefix argument. There's a description of how to regenerate the core models in ModelFactoryImpl.java. My feeling is it would be best to regenerate the core models. Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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;;
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503470 ] Ron Gavlin commented on TUSCANY-513: Hi Kelvin, I do not see CustomerAccount.xsd in the tools project SVN repository. Would you please confirm its existence? Also, is there a good way to include the Apache License header in the code-generated files or is that a manual process? - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
Re: [jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
Ron, apologies, I should have double checked, it was sitting locally on my machine without having been committed. It's there now. As to the apache license, to date I have added them manually. The issue with adding code for the Apache license specifically is of course that for the end user of the generator the code that they generate would not be licensed by Apache in general. We could do something more general to address this some time, or I guess we could add a hook point in the generator for a template method, and do a tiny specialization of the generator for generating tuscany specific classes. Regards, Kelvin. On 11/06/07, Ron Gavlin (JIRA) tuscany-dev@ws.apache.org wrote: [ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503470] Ron Gavlin commented on TUSCANY-513: Hi Kelvin, I do not see CustomerAccount.xsd in the tools project SVN repository. Would you please confirm its existence? Also, is there a good way to include the Apache License header in the code-generated files or is that a manual process? - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/size color value=blue/ /product /ord:items /ord:order Schema Document 1 (chapter04ord1.xsd) xsd:schema
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503542 ] Frank Budinsky commented on TUSCANY-513: Hi Ron, If I understand this, the only template change you made was to rename the getType() method in the generated impl classes to getStaticType(). If that's true, I wounldn't go through all the trouble of regening all the generated models, but instead I would just manually rename the methods in the necessary classes. If we had a better regen story in Tuscany (like EMF has auto merge) that would be a different story. Frank. Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503566 ] Ron Gavlin commented on TUSCANY-513: Hi Frank, Yes, I would like to avoid the ModelFactoryImpl re-generation if possible. Some of the generated test classes had patternVersion updates from 1.1 to 1.2. So, for the generated test classes, my patch will include new versions of these classes. Does that make sense? - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-1.0 Attachments: tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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/
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501533 ] Ron Gavlin commented on TUSCANY-513: Folks, I have attached patches for sdo-impl and sdo-tools to resolve this issue. I apologize that the patch is a bit stale however this is the version of the patch that is approved for contribution. In particular, the sdo-tools JavaGenerator is a bit out of date but the merge should be trivial for you. It would be greatly appreciated if you reviewed and applied this patch prior to the tuscany sdo 1.0 release. If there is anything I can do to help make that happen, let me know. Thanks for your continued support. - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-Next Attachments: tuscany-sdo-impl.TUSCANY-513.patch, tuscany-sdo-tools.TUSCANY-513.patch Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497879 ] Frank Budinsky commented on TUSCANY-513: Hi Ron, You're right that the getStaticType() method should look like the getType() method currently. There should be no generated override of getType(), there should just be a generated getStaticType() mehtod. In DataObjectBase, there will need to be an implementation of getType() that checks if there is a dynamic type associated with the instance and return it if so. If not, call getStaticType() and return it. This is the same pattern that EMF uses to implement the eClass() method by delegating to eStaticClass(). Frank. Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-Mx Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497890 ] Ron Gavlin commented on TUSCANY-513: Got that fixed. Thanks. Now I have run into a problem with an infinite loop attempting to set a property. The stack trace is below. It appears the DataObjectBase.eSet(int, Object) is conflicting with BasicEObjectImpl.eSet(int, Object). Is this a known problem? Any thoughts? - Ron Thread [main] (Suspended) InfoTypeImpl(BasicEObjectImpl).eSet(EStructuralFeature, Object) line: 651 InfoTypeImpl(DataObjectImpl).set(Property, Object) line: 142 InfoTypeImpl(DataObjectImpl).set(int, Object) line: 102 InfoTypeImpl(DataObjectBase).eSet(int, Object) line: 383 InfoTypeImpl(BasicEObjectImpl).eSet(EStructuralFeature, Object) line: 654 InfoTypeImpl(DataObjectImpl).set(Property, Object) line: 142 InfoTypeImpl(DataObjectImpl).set(int, Object) line: 102 InfoTypeImpl(DataObjectBase).eSet(int, Object) line: 383 InfoTypeImpl(BasicEObjectImpl).eSet(EStructuralFeature, Object) line: 654 InfoTypeImpl(DataObjectImpl).set(Property, Object) line: 142 InfoTypeImpl(DataObjectImpl).set(int, Object) line: 102 InfoTypeImpl(DataObjectBase).eSet(int, Object) line: 383 InfoTypeImpl(BasicEObjectImpl).eSet(EStructuralFeature, Object) line: 654 SDOXMLResourceImpl$SDOXMLHelperImpl(XMLHelperImpl).setValue(EObject, EStructuralFeature, Object, int) line: 1050 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).setFeatureValue(EObject, EStructuralFeature, Object, int) line: 2413 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).setFeatureValue(EObject, EStructuralFeature, Object) line: 2403 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).endElement(String, String, String) line: 1344 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.endElement(String, String, String) line: 303 SAXParser(AbstractSAXParser).endElement(QName, Augmentations) line: 633 XMLNSDocumentScannerImpl.scanEndElement() line: 719 XMLNSDocumentScannerImpl$NSContentDispatcher(XMLDocumentFragmentScannerImpl$FragmentContentDispatcher).dispatch(boolean) line: 1685 XMLNSDocumentScannerImpl(XMLDocumentFragmentScannerImpl).scanDocument(boolean) line: 368 JAXPConfiguration(XML11Configuration).parse(boolean) line: 834 JAXPConfiguration(XML11Configuration).parse(XMLInputSource) line: 764 SAXParser(XMLParser).parse(XMLInputSource) line: 148 SAXParser(AbstractSAXParser).parse(InputSource) line: 1242 SAXParserImpl(SAXParser).parse(InputSource, DefaultHandler) line: 375 SDOXMLResourceImpl$SDOXMLLoadImpl(XMLLoadImpl).load(XMLResource, InputSource, Map) line: 265 SDOXMLResourceImpl(XMLResourceImpl).doLoad(InputSource, Map) line: 666 SDOXMLResourceImpl.doLoad(InputSource, Map) line: 465 SDOXMLResourceImpl(XMLResourceImpl).load(InputSource, Map) line: 634 XMLDocumentImpl.load(InputSource, String, Object) line: 259 XMLDocumentImpl.load(InputStream, String, Object) line: 232 XMLHelperImpl.load(InputStream, String, Object) line: 85 XMLHelperImpl.load(InputStream) line: 79 ExtensibleTestCase.testInfoLoad() line: 73 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 585 ExtensibleTestCase(TestCase).runTest() line: 154 ExtensibleTestCase(TestCase).runBare() line: 127 TestResult$1.protect() line: 106 TestResult.runProtected(Test, Protectable) line: 124 TestResult.run(TestCase) line: 109 ExtensibleTestCase(TestCase).run(TestResult) line: 118 JUnit3TestReference.run(TestExecution) line: 128 TestExecution.run(ITestReference[]) line: 38 RemoteTestRunner.runTests(String[], String, TestExecution) line: 460 RemoteTestRunner.runTests(TestExecution) line: 673 RemoteTestRunner.run() line: 386 RemoteTestRunner.main(String[]) line: 196 Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[
https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497899
]
Ron Gavlin commented on TUSCANY-513:
Frank,
I temporarily worked around the problem by replacing the DataObjectBase e[Get,
Set, Unset, IsSet] method implementations with invocations of super.e[Get, Set,
Unset, IsSet]. For example,
public void eSet(int featureID, Object newValue)
{
super.eSet(internalConvertIndex(featureID), newValue);
}
This fixed my problems and now my initial ExtensibleTestCase test passes.
Please let me know if this is the correct fix.
- Ron
Implement support for dynamic subclasses of statically generated types
--
Key: TUSCANY-513
URL: https://issues.apache.org/jira/browse/TUSCANY-513
Project: Tuscany
Issue Type: Improvement
Components: Java SDO Implementation
Reporter: Ron Gavlin
Fix For: Java-SDO-Mx
Implement support for dynamic subclasses of statically generated types. See
below exerpt from tuscany-user mailing list for details.
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
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:number123ABBCC123/ord:number
ord:customer
ord:namePat Walmsley/ord:name
ord:number15465/ord:number
info xsi:type=ns1:InfoType xmlns=
xmlns:ns1=http://example.org/info/zipcode;
zipcode21043/zipcode
/info
/ord:customer
ord:customer
ord:namePriscilla Walmsley/ord:name
ord:number15466/ord:number
info xsi:type=ns1:InfoType xmlns=
xmlns:ns1=http://example.org/info/street;
street341 Duckworth Way/street
/info
/ord:customer
ord:items
product
number557/number
nameShort-Sleeved Linen Blouse/name
size system=US-DRESS10/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/
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497937 ] Ron Gavlin commented on TUSCANY-513: Frank, Nevermind, I think I have it working now. - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-Mx Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497520 ] Ron Gavlin commented on TUSCANY-513: Hi Frank, Please explain the generated getStaticType() method further. Am I correct that its implementation looks just like the current generated getType() implementation? Furthermore, the generated getType() implementation will need to be more dynamic, correct? Should it somehow use the extendedMetaData/TypeHelperImpl to return its type? Your assistance is appreciated. - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-Mx Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496332 ] Frank Budinsky commented on TUSCANY-513: Hi Ron, I think that maybe we should start without an option - i.e., just make DataObjectBase support extensibility. I would suggest adding a new subclass of DataObjectImpl, ExtensibleDataObjectImpl, and then change DataObjectBase to subclass from it (instead of DataObjectImpl). No generator option needed at this point. If we decide that we later want the higher performance non extensible DataObject, we can add an option in the future. Note: I think we have a problem with the noEMF pattern, related to extensibility: we generate an override of the getType() method in the generated classes. The generator template will need to be changed to generate a getStaticType() method, similar to EMF's eStaticClass() method, to fix this problem. Otherwise, I don't see any complications with the noEMF pattern. Frank. Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-Mx Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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;;
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496362 ] Ron Gavlin commented on TUSCANY-513: Hi Frank, Your suggestion makes sense. I'll keep you updated on my progress and ask questions as needed. - Ron Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: https://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Ron Gavlin Fix For: Java-SDO-Mx Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[
https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496116
]
Ron Gavlin commented on TUSCANY-513:
Greetings,
I am in the process of trying to port my local solution to this JIRA from M2 to
the head. Once I finish, I hope to contribute these changes back to the
community. I have a question related to the new, default, noEMF pattern which
now relies on DataObjectBase. In the M2 days, it was trivial for me to create
and configure a ExtensibleDataObjectImpl class as a cut-and-paste from
DynamicDataObjectImpl with the following minor tweaks:
1. Remove
protected int eStaticFeatureCount()
{
return 0;
}
2. Change
public EClass eClass()
{
return eClass;
}
To
public EClass eClass()
{
return (eClass == null) ? eStaticClass() : eClass;
}
The new noEMF pattern using DataObjectBase is more complicated. Here are my
initial questions.
1. Are we still in agreement that the JavaGenerator will have a
noExtensibility flag to indicate that generated classes should extend the
existing DataObjectBase class rather than the new, default
ExtensibleDataObjectBase class being developed as part of this JIRA?
2. Would you provide hints and/or suggested steps for for taking the goodness
in DynamicDataObjectImpl and using it to create a new ExtensibleDataObjectBase
class that either extends DataObjectBase or DataObjectImpl?
Thanks in advance for your assistance.
- Ron
Implement support for dynamic subclasses of statically generated types
--
Key: TUSCANY-513
URL: https://issues.apache.org/jira/browse/TUSCANY-513
Project: Tuscany
Issue Type: Improvement
Components: Java SDO Implementation
Reporter: Ron Gavlin
Fix For: Java-SDO-Mx
Implement support for dynamic subclasses of statically generated types. See
below exerpt from tuscany-user mailing list for details.
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
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:number123ABBCC123/ord:number
ord:customer
ord:namePat Walmsley/ord:name
ord:number15465/ord:number
info xsi:type=ns1:InfoType xmlns=
xmlns:ns1=http://example.org/info/zipcode;
zipcode21043/zipcode
/info
/ord:customer
ord:customer
ord:namePriscilla Walmsley/ord:name
ord:number15466/ord:number
info xsi:type=ns1:InfoType xmlns=
xmlns:ns1=http://example.org/info/street;
[jira] Commented: (TUSCANY-513) Implement support for dynamic subclasses of statically generated types
[ http://issues.apache.org/jira/browse/TUSCANY-513?page=comments#action_12456993 ] Frank Budinsky commented on TUSCANY-513: Hi Ron, I'm wondering what the status of this is. We need to get this function into Tuscany soon, so we'd like to start on it now. As you may have noticed, we've completely deprecated the old EMF-style generator pattern, so we don't need to do this in two places. I'd very much appreciate it if you could provide a patch with what you've done. If you'd like, I'd be happy to take what you've got, and rework it to fit into the latest design. Please let me know, if you're still able to help with this. Thanks, Frank Implement support for dynamic subclasses of statically generated types -- Key: TUSCANY-513 URL: http://issues.apache.org/jira/browse/TUSCANY-513 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Ron Gavlin Fix For: Java-Mx Implement support for dynamic subclasses of statically generated types. See below exerpt from tuscany-user mailing list for details. 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 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:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/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
