castor
  1. castor
  2. CASTOR-1917

Source generator does not fail on unresolved element types instead it sets them as java.lang.Object

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 1.2
    • Component/s: XML code generator
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      4

      Description

      In the previous version of castor i was using (0.9.5) if you had an element with a type that did not exist in the schema then the source generation would fail but with 1.1 it simply makes the type a java.lang.Object and procedes happily.

      using the following schema (note that there is no declaration of type 'blahblahblah'):

      <?xml version="1.0" encoding="UTF-8"?>
      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <xs:simpleType name="HOST">
      <xs:restriction base="xs:string"/>
      </xs:simpleType>
      <xs:simpleType name="ID">
      <xs:restriction base="xs:string"/>
      </xs:simpleType>
      <xs:simpleType name="PASSWORD">
      <xs:restriction base="xs:string"/>
      </xs:simpleType>
      <xs:complexType name="FLOWER">
      <xs:sequence>
      <xs:element name="HOST" type="HOST"/>
      <xs:element name="ID" type="blahblahblah" />
      <xs:element name="PASSWORD" type="PASSWORD"/>
      </xs:sequence>
      </xs:complexType>
      </xs:schema>

      with castor 0.9.x you get the following error:

      [javac] FLOWER.java:47: cannot find symbol
      [javac] symbol : class ID
      [javac] location: package mypackage.common
      [javac] private mypacakge.common.ID _ID;
      [javac] ^

      but with castor 1.1 it happily builds the source setting the property 'ID' to a java.lang.Object in the source file.

      attached is the bug template where i've only touched files in srcgen-bug.zip\bugs\xml\srcgen\template\ (i replaced the schema, and added some settings to the SourceGenerator object.

        Activity

        Hide
        Werner Guttmann added a comment -

        It looks like this is related to an oldish (BugZilla) bug with the number of 1471, where the following code is executed within MemberFactory.createFieldInfo() is the xsType is null.

        if (xsType == null) {
        //-- patch for bug 1471 (No XMLType specified)
        //-- treat unspecified type as anyType
        switch (component.getAnnotated().getStructureType())

        { case Structure.ATTRIBUTE: case Structure.ELEMENT: xsType = new XSClass(SGTypes.OBJECT); break; default: // probably a model-group break; }

        }

        Which makes me wonder why we get that far at all .. .

        Show
        Werner Guttmann added a comment - It looks like this is related to an oldish (BugZilla) bug with the number of 1471, where the following code is executed within MemberFactory.createFieldInfo() is the xsType is null. if (xsType == null) { //-- patch for bug 1471 (No XMLType specified) //-- treat unspecified type as anyType switch (component.getAnnotated().getStructureType()) { case Structure.ATTRIBUTE: case Structure.ELEMENT: xsType = new XSClass(SGTypes.OBJECT); break; default: // probably a model-group break; } } Which makes me wonder why we get that far at all .. .
        Hide
        Werner Guttmann added a comment -

        I think that it should be easy to provide a patch that restores old (pre-1.0) behaviour, but somehow I think that an exception should be thrown instead to indicate that there's a type reference that cannot be resolved.

        Show
        Werner Guttmann added a comment - I think that it should be easy to provide a patch that restores old (pre-1.0) behaviour, but somehow I think that an exception should be thrown instead to indicate that there's a type reference that cannot be resolved.
        Hide
        Simon Lord added a comment -

        I agree - and it would make debugging easier if an exception was thrown that indicated that there's a type reference that cannot be resolved.

        Show
        Simon Lord added a comment - I agree - and it would make debugging easier if an exception was thrown that indicated that there's a type reference that cannot be resolved.
        Hide
        Werner Guttmann added a comment -

        Initial patch for reviw, working around the 'java.lang.Object' problem, returning to uncompilable code for such unresolvable type references.

        Show
        Werner Guttmann added a comment - Initial patch for reviw, working around the 'java.lang.Object' problem, returning to uncompilable code for such unresolvable type references.
        Hide
        Werner Guttmann added a comment -

        Before I can commit this patch, there's a few issues related to two or three broken CTF tests that need to sorted. In addition, I need a way to make a generation-only test as failing.

        Show
        Werner Guttmann added a comment - Before I can commit this patch, there's a few issues related to two or three broken CTF tests that need to sorted. In addition, I need a way to make a generation-only test as failing.
        Hide
        Werner Guttmann added a comment -

        Final patch for review.

        Show
        Werner Guttmann added a comment - Final patch for review.
        Hide
        Werner Guttmann added a comment -

        Simon, can I ask you to create a follow-up issue for the change with regards to exception handling. I'd like to make this patch available to restore things to pre-1.0 mode for the upcoming 1.2 release.

        Show
        Werner Guttmann added a comment - Simon, can I ask you to create a follow-up issue for the change with regards to exception handling. I'd like to make this patch available to restore things to pre-1.0 mode for the upcoming 1.2 release.
        Hide
        Werner Guttmann added a comment -

        Updated patch, replacing all other patches attached.

        Show
        Werner Guttmann added a comment - Updated patch, replacing all other patches attached.

          People

          • Assignee:
            Werner Guttmann
            Reporter:
            Simon Lord
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 30 minutes
              30m