castor
  1. castor
  2. CASTOR-1839

Schema with imported simpletypes generates incorrect Java code

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.5
    • Fix Version/s: 1.1 M3
    • Component/s: XML code generator
    • Labels:
      None
    • Number of attachments :
      5

      Description

      A schema which defines a simpletype using a restriction-base from an imported schema generates incorrect Java-code.

      In the attached schema look at the LanguageCode, which is of a simpletype defined in the same schema. this type is based on a LanguageCodeType from an imported schema.

      <xsd:complexType name="BusinessObjectDocumentType">
      <xsd:attribute name="languageCode" type="LanguageCodeType" use="optional" default="en-US"> </xsd:attribute>
      </xsd:complexType>

      <xsd:simpleType name="LanguageCodeType">
      <xsd:restriction base="qdt:LanguageCodeType"/>
      </xsd:simpleType>

      This generated javacode looks like:
      private java.lang.Object _languageCode = new java.lang.Object("en-US");

      1. patch.c1839.20071217.txt
        1.0 kB
        Werner Guttmann
      2. patch.c1839.tests.20070118.txt
        54 kB
        Werner Guttmann

        Activity

        Hide
        Daniel Nilsson added a comment -

        Sorry for the delay.
        Attached is an initial workinprogress of the schemas I am to create the sources for I created a sample document with Alatova XML spy which

        There is anyhow a part which looks like this:

        Show
        Daniel Nilsson added a comment - Sorry for the delay. Attached is an initial workinprogress of the schemas I am to create the sources for I created a sample document with Alatova XML spy which There is anyhow a part which looks like this:
        Hide
        Daniel Nilsson added a comment -

        hmm, and that is what happens when you accedently hit Enter...

        Ok, to complete the previous message:

        I created a sample xml-document with XmlSpy from the xsd since I don't have any other samples at this moment.
        There is also a section in the xsd looking like:
        <xsd:complexType name="UserAreaType" block="restriction">
        <xsd:sequence>
        <xsd:any namespace="##any" processContents="strict" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
        </xsd:complexType>
        which I havn't tried with castor. If it doesnät work let me know and I can strip that part out from the sample.

        Show
        Daniel Nilsson added a comment - hmm, and that is what happens when you accedently hit Enter... Ok, to complete the previous message: I created a sample xml-document with XmlSpy from the xsd since I don't have any other samples at this moment. There is also a section in the xsd looking like: <xsd:complexType name="UserAreaType" block="restriction"> <xsd:sequence> <xsd:any namespace="##any" processContents="strict" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> which I havn't tried with castor. If it doesnät work let me know and I can strip that part out from the sample.
        Hide
        Daniel Nilsson added a comment -

        removed some unnecassary binding-files

        Show
        Daniel Nilsson added a comment - removed some unnecassary binding-files
        Hide
        Werner Guttmann added a comment -

        Daniel, with the last archive you attached, code generation completes with errors. Any idea why ?

        Show
        Werner Guttmann added a comment - Daniel, with the last archive you attached, code generation completes with errors. Any idea why ?
        Hide
        Werner Guttmann added a comment -

        Actually, found the problem. Just committed the new CTF test case (based upon your sample), and included a small patch to JDescriptorClass to fix an issue related to incorrect import statements for descriptor classes that extend another descriptor, and not XMLClassDescriptorImpl.

        Show
        Werner Guttmann added a comment - Actually, found the problem. Just committed the new CTF test case (based upon your sample), and included a small patch to JDescriptorClass to fix an issue related to incorrect import statements for descriptor classes that extend another descriptor, and not XMLClassDescriptorImpl.

          People

          • Assignee:
            Werner Guttmann
            Reporter:
            Daniel Nilsson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 4 hours
              4h
              Remaining:
              Time Spent - 1 hour, 50 minutes Remaining Estimate - 2 hours, 10 minutes
              2h 10m
              Logged:
              Time Spent - 1 hour, 50 minutes Remaining Estimate - 2 hours, 10 minutes
              1h 50m