Tuscany
  1. Tuscany
  2. TUSCANY-513

Implement support for dynamic subclasses of statically generated types

    Details

    • Patch Info:
      Patch Available

      Description

      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:number>123ABBCC123</ord:number>
      > <ord:customer>
      > <ord:name>Pat Walmsley</ord:name>
      > <ord:number>15465</ord:number>
      > <info xsi:type="ns1:InfoType" xmlns=""
      > xmlns:ns1="<http://example.org/info/zipcode>";>
      > <zipcode>21043</zipcode>
      > </info>
      > </ord:customer>
      > <ord:customer>
      > <ord:name>Priscilla Walmsley</ord:name>
      > <ord:number>15466</ord:number>
      > <info xsi:type="ns1:InfoType" xmlns=""
      > xmlns:ns1="<http://example.org/info/street>";>
      > <street>341 Duckworth Way</street>
      > </info>
      > </ord:customer>
      > <ord:items>
      > <product>
      > <number>557</number>
      > <name>Short-Sleeved Linen Blouse</name>
      > <size system="US-DRESS">10</size>
      > <color value="blue"/>
      > </product>
      > </ord:items>
      > </ord:order>
      > Schema Document 1 (chapter04ord1.xsd)
      > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;
      > targetNamespace="<http://example.org/ord>";;
      > xmlns="<http://example.org/ord>";;
      > xmlns:prod="<http://example.org/prod>";;
      > elementFormDefault="qualified">
      > <xsd:import namespace="<http://example.org/prod>";;
      > schemaLocation="chapter04prod.xsd"/>
      > <xsd:simpleType name="OrderNumType">
      > <xsd:restriction base="xsd:string"/>
      > </xsd:simpleType>
      > <xsd:complexType name="InfoType"/>
      > <xsd:complexType name="CustomerType">
      > <xsd:sequence>
      > <xsd:element name="name" type="CustNameType"/>
      > <xsd:element name="number" type="xsd:integer"/>
      > <xsd:element name="info" type="InfoType" form="unqualified"/>
      > </xsd:sequence>
      > </xsd:complexType>
      > <xsd:simpleType name="CustNameType">
      > <xsd:restriction base="xsd:string"/>
      > </xsd:simpleType>
      > <xsd:element name="order" type="OrderType"/>
      > <xsd:complexType name="OrderType">
      > <xsd:sequence>
      > <xsd:element name="number" type="OrderNumType"/>
      > <xsd:element name="customer" type="CustomerType"
      > maxOccurs="unbounded"/>
      > <xsd:element name="items" type="prod:ItemsType"/>
      > </xsd:sequence>
      > </xsd:complexType>
      > </xsd:schema>
      > Schema Document 2 (chapter04infozipcode.xsd)
      > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;
      > xmlns:ord="<http://example.org/ord>";;
      > xmlns="<http://example.org/info/zipcode>";;
      > targetNamespace="<http://example.org/info/zipcode>";;
      > elementFormDefault="unqualified">
      > <xsd:import namespace="<http://example.org/ord>";;
      > schemaLocation="chapter04ord1.xsd"/>
      > <xsd:complexType name="InfoType">
      > <xsd:complexContent>
      > <xsd:extension base="ord:InfoType">
      > <xsd:sequence>
      > <xsd:element name="zipcode" type="xsd:string"/>
      > </xsd:sequence>
      > </xsd:extension>
      > </xsd:complexContent>
      > </xsd:complexType>
      > </xsd:schema>
      > Schema Document 3 (chapter04infostreet.xsd)
      > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;
      > xmlns:ord="<http://example.org/ord>";;
      > xmlns="<http://example.org/info/street>";;
      > targetNamespace="<http://example.org/info/street>";;
      > elementFormDefault="unqualified">
      > <xsd:import namespace="<http://example.org/ord>";;
      > schemaLocation="chapter04ord1.xsd"/>
      > <xsd:complexType name="InfoType">
      > <xsd:complexContent>
      > <xsd:extension base="ord:InfoType">
      > <xsd:sequence>
      > <xsd:element name="street" type="xsd:string"/>
      > </xsd:sequence>
      > </xsd:extension>
      > </xsd:complexContent>
      > </xsd:complexType>
      > </xsd:schema>
      > Schema Document 4 (chapter04prod.xsd)
      > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;
      > xmlns="<http://example.org/prod>";;
      > targetNamespace="<http://example.org/prod>";;
      > elementFormDefault="unqualified">
      > <xsd:complexType name="ItemsType">
      > <xsd:sequence>
      > <xsd:element name="product" type="ProductType"/>
      > </xsd:sequence>
      > </xsd:complexType>
      > <xsd:complexType name="ProductType">
      > <xsd:sequence>
      > <xsd:element name="number" type="xsd:integer"/>
      > <xsd:element name="name" type="xsd:string"/>
      > <xsd:element name="size" type="SizeType"/>
      > <xsd:element name="color" type="ColorType"/>
      > </xsd:sequence>
      > </xsd:complexType>
      > <xsd:complexType name="SizeType">
      > <xsd:simpleContent>
      > <xsd:extension base="xsd:integer">
      > <xsd:attribute name="system" type="xsd:string"/>
      > </xsd:extension>
      > </xsd:simpleContent>
      > </xsd:complexType>
      > <xsd:complexType name="ColorType">
      > <xsd:attribute name="value" type="xsd:string"/>
      > </xsd:complexType>
      > </xsd:schema>
      >

      1. tuscany-sdo-impl.TUSCANY-513.patch
        23 kB
        Ron Gavlin
      2. tuscany-sdo-tools.TUSCANY-513.patch
        4 kB
        Ron Gavlin
      3. tuscany-sdo-impl.TUSCANY-513.2.patch
        47 kB
        Ron Gavlin
      4. tuscany-sdo-tools.TUSCANY-513.2.patch
        118 kB
        Ron Gavlin

        Issue Links

          Activity

          Ron Gavlin created issue -
          Hide
          Ron Gavlin added a comment -

          I am trying to put together a patch to address this problem. In doing so, I have defined a new class ExtensibleDataObjectImpl that extends DataObjectImpl and added a new option to JavaGenerator named -noExtensibility which may be set as a performance optimization to turn off the default extensibility behavior.

          While putting together the patch, I noticed the JavaGenerator -noEMF option is supported by the root class DataObjectBase. Thus, it appears I'll need to add an ExtensibleDataObjectBase class which extends ExtensibleDataObjectImpl, correct? Do you see an easy way to share the functionality currently in DataObjectBase w/ExtensibleDataObjectBase? Your thoughts are appreciated.

          • Ron
          Show
          Ron Gavlin added a comment - I am trying to put together a patch to address this problem. In doing so, I have defined a new class ExtensibleDataObjectImpl that extends DataObjectImpl and added a new option to JavaGenerator named -noExtensibility which may be set as a performance optimization to turn off the default extensibility behavior. While putting together the patch, I noticed the JavaGenerator -noEMF option is supported by the root class DataObjectBase. Thus, it appears I'll need to add an ExtensibleDataObjectBase class which extends ExtensibleDataObjectImpl, correct? Do you see an easy way to share the functionality currently in DataObjectBase w/ExtensibleDataObjectBase? Your thoughts are appreciated. Ron
          Hide
          Frank Budinsky added a comment -

          Ron,

          The plan is to make noEMF the default pattern in the near future, right after M2. Eventually we will want to deprecate the EMF-based generation. So, I'm wondering if all we really need is ExtensibleDatatObjectBase - that is, only support extensibility in conjunction with the noEMF pattern. Would that work for you, or do you need it with the EMF-based pattern?

          If we need it in both cases, then I need to see it before I can make any suggestions for code sharing. Maybe you should just start by implementing the one you need, and we can figure out after that how to make it work for the other pattern, if necessary.

          Thanks,
          Frank.

          Show
          Frank Budinsky added a comment - Ron, The plan is to make noEMF the default pattern in the near future, right after M2. Eventually we will want to deprecate the EMF-based generation. So, I'm wondering if all we really need is ExtensibleDatatObjectBase - that is, only support extensibility in conjunction with the noEMF pattern. Would that work for you, or do you need it with the EMF-based pattern? If we need it in both cases, then I need to see it before I can make any suggestions for code sharing. Maybe you should just start by implementing the one you need, and we can figure out after that how to make it work for the other pattern, if necessary. Thanks, Frank.
          ant elder made changes -
          Field Original Value New Value
          Fix Version/s Java-Mx [ 12311031 ]
          Affects Version/s Java-M1 [ 12311030 ]
          Affects Version/s Java-Mx [ 12311031 ]
          Hide
          Frank Budinsky added a comment -

          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

          Show
          Frank Budinsky added a comment - 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
          Hide
          Kelvin Goodson added a comment -

          I am planning to take a look at this, starting in a couple of days time I hope. It looks like Ron may have had a partial solution at one point. Would you be able to attach whatever you have Ron, as a starting point for me? Don't worry if its broken or incomplete, it just might help me get a head start.

          Show
          Kelvin Goodson added a comment - I am planning to take a look at this, starting in a couple of days time I hope. It looks like Ron may have had a partial solution at one point. Would you be able to attach whatever you have Ron, as a starting point for me? Don't worry if its broken or incomplete, it just might help me get a head start.
          ant elder made changes -
          Fix Version/s Java-SDO-Mx [ 12312262 ]
          Fix Version/s Java-Mx [ 12311031 ]
          Hide
          Ron Gavlin added a comment -

          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
          Show
          Ron Gavlin added a comment - 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
          Hide
          Frank Budinsky added a comment -

          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.

          Show
          Frank Budinsky added a comment - 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.
          Hide
          Ron Gavlin added a comment -

          Hi Frank,

          Your suggestion makes sense. I'll keep you updated on my progress and ask questions as needed.

          • Ron
          Show
          Ron Gavlin added a comment - Hi Frank, Your suggestion makes sense. I'll keep you updated on my progress and ask questions as needed. Ron
          Hide
          Ron Gavlin added a comment -

          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
          Show
          Ron Gavlin added a comment - 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
          Hide
          Frank Budinsky added a comment -

          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.

          Show
          Frank Budinsky added a comment - 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.
          Hide
          Ron Gavlin added a comment -

          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

          Show
          Ron Gavlin added a comment - 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
          Hide
          Ron Gavlin added a comment -

          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
          Show
          Ron Gavlin added a comment - 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
          Hide
          Ron Gavlin added a comment -

          Frank,

          Nevermind, I think I have it working now.

          • Ron
          Show
          Ron Gavlin added a comment - Frank, Nevermind, I think I have it working now. Ron
          Ron Gavlin made changes -
          Attachment tuscany-sdo-impl.TUSCANY-513.patch [ 12358950 ]
          Ron Gavlin made changes -
          Attachment tuscany-sdo-tools.TUSCANY-513.patch [ 12358951 ]
          Ron Gavlin made changes -
          Attachment tuscany-sdo-impl.TUSCANY-513.patch [ 12358950 ]
          Ron Gavlin made changes -
          Attachment tuscany-sdo-tools.TUSCANY-513.patch [ 12358951 ]
          Ron Gavlin made changes -
          Attachment tuscany-sdo-impl.TUSCANY-513.patch [ 12358952 ]
          Ron Gavlin made changes -
          Attachment tuscany-sdo-tools.TUSCANY-513.patch [ 12358953 ]
          Hide
          Ron Gavlin added a comment -

          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
          Show
          Ron Gavlin added a comment - 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
          Ron Gavlin made changes -
          Patch Info [Patch Available]
          Hide
          Kelvin Goodson added a comment -

          Setting target version to SDO Java 1.0 to reflect Ron's wishes

          Show
          Kelvin Goodson added a comment - Setting target version to SDO Java 1.0 to reflect Ron's wishes
          Kelvin Goodson made changes -
          Fix Version/s Java-SDO-1.0 [ 12312521 ]
          Fix Version/s Java-SDO-Next [ 12312262 ]
          Hide
          Kelvin Goodson added a comment -

          Hi Ron, thanks for this. Would you be able to supply the harnesses you've been using to exercise this for testing purposes please?

          Show
          Kelvin Goodson added a comment - Hi Ron, thanks for this. Would you be able to supply the harnesses you've been using to exercise this for testing purposes please?
          Hide
          Ron Gavlin added a comment -

          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
          Show
          Ron Gavlin added a comment - 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
          Hide
          Ron Gavlin added a comment -

          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?

          Show
          Ron Gavlin added a comment - 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?
          Hide
          Ron Gavlin added a comment -

          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
          Show
          Ron Gavlin added a comment - 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
          Hide
          Kelvin Goodson added a comment -

          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.

          Show
          Kelvin Goodson added a comment - 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.
          Hide
          Ron Gavlin added a comment -

          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
          Show
          Ron Gavlin added a comment - 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
          Hide
          Frank Budinsky added a comment -

          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.

          Show
          Frank Budinsky added a comment - 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.
          Hide
          Ron Gavlin added a comment -

          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
          Show
          Ron Gavlin added a comment - 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
          Ron Gavlin made changes -
          Attachment tuscany-sdo-impl.TUSCANY-513.2.patch [ 12359591 ]
          Ron Gavlin made changes -
          Attachment tuscany-sdo-tools.TUSCANY-513.2.patch [ 12359592 ]
          Hide
          Ron Gavlin added a comment -

          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
          Show
          Ron Gavlin added a comment - 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
          Hide
          Kelvin Goodson added a comment -

          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.

          Show
          Kelvin Goodson added a comment - 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.
          Hide
          Kelvin Goodson added a comment -

          See my earlier comment

          Show
          Kelvin Goodson added a comment - See my earlier comment
          Kelvin Goodson made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Hide
          Ron Gavlin added a comment -

          Kelvin,

          My pleasure. Thanks for reviewing and applying this patch so quickly.

          Regards,

          • Ron
          Show
          Ron Gavlin added a comment - Kelvin, My pleasure. Thanks for reviewing and applying this patch so quickly. Regards, Ron
          Murtaza Goga made changes -
          Link This issue relates to TUSCANY-1540 [ TUSCANY-1540 ]
          Hide
          ant elder added a comment -

          Closing because this has been in RESOLVED state for over one year, if it turns out to not be fixed please reopen.

          Show
          ant elder added a comment - Closing because this has been in RESOLVED state for over one year, if it turns out to not be fixed please reopen.
          ant elder made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Ron Gavlin
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development