castor
  1. castor
  2. CASTOR-1146

can't generate proper java classes for redefined complexType

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: 0.9.6
    • Fix Version/s: None
    • Component/s: XML code generator
    • Labels:
      None
    • Number of attachments :
      1

      Description

      snippet of generated BodyType.java

      ...
      public class BodyType extends BodyType // <----- bug implements java.io.Serializable { ...

      base.xsd

      <?xml version="1.0" encoding="UTF-8"?>
      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
      elementFormDefault="qualified"

      attributeFormDefault="unqualified">
      <xs:annotation>
      <xs:documentation>base schema</xs:documentation>
      </xs:annotation>
      <xs:element name="Document">
      <xs:complexType>
      <xs:sequence>
      <xs:element name="Body" type="BodyType"/>
      </xs:sequence>
      </xs:complexType>
      </xs:element>
      <xs:complexType name="BodyType">
      <xs:sequence>
      <xs:any namespace="##any" processContents="lax" minOccurs="0"
      maxOccurs="unbounded"/>
      </xs:sequence>
      </xs:complexType>
      </xs:schema>

      redefined.xsd(redefine complexType "BodyType" in above base.xsd)

      <?xml version="1.0" encoding="UTF-8"?>
      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
      elementFormDefault="qualified"

      attributeFormDefault="unqualified">
      <xs:redefine schemaLocation="base.xsd">
      <!-- yes, BodyType will be redefined here -->
      <xs:complexType name="BodyType">
      <xs:complexContent>
      <!-- BodyType in base.xsd -->
      <xs:restriction base="BodyType">
      <xs:sequence>
      <xs:element name="AccountName">
      <xs:annotation>
      <xs:documentation>account name</xs:documentation>
      </xs:annotation>
      <xs:simpleType>
      <xs:restriction base="xs:string">
      <xs:maxLength value="20"/>
      </xs:restriction>
      </xs:simpleType>
      </xs:element>
      <xs:element name="Password">
      <xs:annotation>
      <xs:documentation>password</xs:documentation>
      </xs:annotation>
      <xs:simpleType>
      <xs:restriction base="xs:string">
      <xs:maxLength value="20"/>
      </xs:restriction>
      </xs:simpleType>
      </xs:element>
      </xs:sequence>
      </xs:restriction>
      </xs:complexContent>
      </xs:complexType>
      </xs:redefine>
      </xs:schema>

      Work Around

      RCS file:
      /home/projects/castor/scm/castor/src/main/org/exolab/castor/builder/SourceFactory.java,v
      retrieving revision 1.16
      diff -r1.16 SourceFactory.java
      1383c1383,1384
      < if (! ( complexType.isRestricted() &&
      ((ComplexType)base).isSimpleContent() ) )

      > if (! ( complexType.isRestricted() &&
      ((ComplexType)base).isSimpleContent() )
      > && !state.jClass.getName().equals(baseClassName))

      BTW, I've checked the newest version of SourceFactory.java and the bug still exist.

      Sorry for that bugzilla post(bug 1938) and thank you keith for correcting me

        Activity

        Hide
        Werner Guttmann added a comment -

        Are you using a custom castorbuilder.properties file by any chance ?

        Show
        Werner Guttmann added a comment - Are you using a custom castorbuilder.properties file by any chance ?
        Hide
        Werner Guttmann added a comment -

        If not, I have just generated Java classes from the XML schemas given, and there's no compilation errors anymore (this is against SVN trunk). As such, I will resolve this issue to 'duplicate' if there's no objections.

        Show
        Werner Guttmann added a comment - If not, I have just generated Java classes from the XML schemas given, and there's no compilation errors anymore (this is against SVN trunk). As such, I will resolve this issue to 'duplicate' if there's no objections.
        Hide
        Werner Guttmann added a comment -

        Actually, if there's objections of any kind, please feel free to reopen this issue.

        Show
        Werner Guttmann added a comment - Actually, if there's objections of any kind, please feel free to reopen this issue.
        Hide
        Werner Guttmann added a comment -

        Actually, taking back my previous comments, this is still a valid issue with 1.0.5. SourceFactory.processComplexType(ComplexType ....) simply is not capable of coping with redefinitions.

        Show
        Werner Guttmann added a comment - Actually, taking back my previous comments, this is still a valid issue with 1.0.5. SourceFactory.processComplexType(ComplexType ....) simply is not capable of coping with redefinitions.
        Hide
        Werner Guttmann added a comment -

        Hmmm, in SourceFactory, lines 1687ff, the condition to be 'tighened' is actually commented out, as per the following comment:

        /*
        Note: There are times when a simpleContent restriction needs to
        extend the hierarchy, such as a restriction of a restriction, so
        I'm commenting out the following line for now. see bug 1875
        for more details. If this causes any regressions we'll need to
        find a more appropriate solution.
        if (! ( complexType.isRestricted() && ((ComplexType)base).isSimpleContent() ) )
        */

        In other words, it looks like the original assumption about this code, as expressed in

        // only set a super class name if the current complexType is not a
        // restriction of a simpleContent (--> no object hierarchy, only content hierarchy)

        is .. well, invalid.

        Show
        Werner Guttmann added a comment - Hmmm, in SourceFactory, lines 1687ff, the condition to be 'tighened' is actually commented out, as per the following comment: /* Note: There are times when a simpleContent restriction needs to extend the hierarchy, such as a restriction of a restriction, so I'm commenting out the following line for now. see bug 1875 for more details. If this causes any regressions we'll need to find a more appropriate solution. if (! ( complexType.isRestricted() && ((ComplexType)base).isSimpleContent() ) ) */ In other words, it looks like the original assumption about this code, as expressed in // only set a super class name if the current complexType is not a // restriction of a simpleContent (--> no object hierarchy, only content hierarchy) is .. well, invalid.
        Hide
        Dureek Wu added a comment -

        It is now 2 years past this bug. As I recalled, I used XMLBeans instead of Castor because of this blocking issue.
        Anyway, I do think Castor is a great data binding tool, please keep up the good work.

        Thanks,
        Dureek Wu

        Show
        Dureek Wu added a comment - It is now 2 years past this bug. As I recalled, I used XMLBeans instead of Castor because of this blocking issue. Anyway, I do think Castor is a great data binding tool, please keep up the good work. Thanks, Dureek Wu
        Hide
        Werner Guttmann added a comment -

        Dureek, I guess I can tell how you must feel about this. But there's nothing I (personally) can do about this, as it's an open source project by nature. Unless there's more (and more) people willing to spend some time not just using Castor, but actually assessing the sources and coming up with (preliminary) patches (which we usually try to integrate as quickly as possible), time will be limited.

        Having said that; I am actually thinking about coming up with new ideas re: bug resolution and dealing with required 'funding'. In other words, stay tuned ... .

        Show
        Werner Guttmann added a comment - Dureek, I guess I can tell how you must feel about this. But there's nothing I (personally) can do about this, as it's an open source project by nature. Unless there's more (and more) people willing to spend some time not just using Castor, but actually assessing the sources and coming up with (preliminary) patches (which we usually try to integrate as quickly as possible), time will be limited. Having said that; I am actually thinking about coming up with new ideas re: bug resolution and dealing with required 'funding'. In other words, stay tuned ... .
        Hide
        Werner Guttmann added a comment -

        And please don't forget that 'voting' is an instrument to raise our perception of an issue in terms of its urgency.

        Show
        Werner Guttmann added a comment - And please don't forget that 'voting' is an instrument to raise our perception of an issue in terms of its urgency.
        Hide
        Werner Guttmann added a comment -

        JUnit test case to reproduce this problem.

        Show
        Werner Guttmann added a comment - JUnit test case to reproduce this problem.

          People

          • Assignee:
            Unassigned
            Reporter:
            Dureek Wu
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: