castor
  1. castor
  2. CASTOR-1565

Class generated from restricted type no longer compiles

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: 1.0.3
    • Fix Version/s: None
    • Component/s: XML
    • Labels:
      None
    • Number of attachments :
      2

      Description

      When a type extends another type but restricts the content, the generated classes will not compile since the return type of the base class is not the same as for the subclass.

      Attached you will find a slice of UBL 1.0 that demonstrates the problem by running Ant. The compiler output is
      ...\se\exder\external\ubl\sdt\UBLAmountType.java:80: getAmountCurrencyID() in se.exder.external.ubl.sdt.UBLAmountType cannot override getAmountCurrencyID() in se.exder.external.ubl.udt.AmountType; attempting to use incompatible return type
      found : se.exder.external.ubl.codelist.types.CurrencyCodeContentType
      required: java.lang.String
      public se.exder.external.ubl.codelist.types.CurrencyCodeContentType getAmountCurrencyID()

      This was no problem in version 0.9.9.1 but prevents one from using Castor 1.x for UBL (or other complex/core component) schemas.

        Activity

        Hide
        Werner Guttmann added a comment -

        Mattias, there's actually a second problem that manifests itself through this set of XMl schemas, i.e. the fact that the unmarshal method is generated incorrectly as well.

        Show
        Werner Guttmann added a comment - Mattias, there's actually a second problem that manifests itself through this set of XMl schemas, i.e. the fact that the unmarshal method is generated incorrectly as well.
        Hide
        Werner Guttmann added a comment -

        Mattias, for the problem with the unmarshal() methods (incorrect return types being used), I have created a separate sub-task.

        Show
        Werner Guttmann added a comment - Mattias, for the problem with the unmarshal() methods (incorrect return types being used), I have created a separate sub-task.
        Hide
        Werner Guttmann added a comment -

        Mattias, are you in a position to provide me with a patch that you are internally using to make 1.0 work (as 0.9.9.1 did) ?

        Show
        Werner Guttmann added a comment - Mattias, are you in a position to provide me with a patch that you are internally using to make 1.0 work (as 0.9.9.1 did) ?
        Hide
        Mattias Jiderhamn added a comment -

        "Mattias, are you in a position to provide me with a patch that you are internally using to make 1.0 work (as 0.9.9.1 did)"

        No. And I probably won't have time to give it a try within this week nor the next one. I'll get back if I make such a patch.

        Show
        Mattias Jiderhamn added a comment - "Mattias, are you in a position to provide me with a patch that you are internally using to make 1.0 work (as 0.9.9.1 did)" No. And I probably won't have time to give it a try within this week nor the next one. I'll get back if I make such a patch.
        Hide
        Werner Guttmann added a comment -

        No problem. Back to the subject of this issue ...

        I am just reading http://www.w3.org/TR/xmlschema-0/#DerivByRestrict, and it looks to me that actually changing the type of an attribute as a result of a restriction is not an option with XML schemas. Having said that, this is the XML schema primer, so I will try to hunt down the relevant spec fragments from the parts 1 and 2 of the XML schema spec.

        Show
        Werner Guttmann added a comment - No problem. Back to the subject of this issue ... I am just reading http://www.w3.org/TR/xmlschema-0/#DerivByRestrict , and it looks to me that actually changing the type of an attribute as a result of a restriction is not an option with XML schemas. Having said that, this is the XML schema primer, so I will try to hunt down the relevant spec fragments from the parts 1 and 2 of the XML schema spec.
        Hide
        Werner Guttmann added a comment -

        Mattias, can you please attach a valid and well-formed sample XML document that unmarshals successfully against the schemas attached ?

        Show
        Werner Guttmann added a comment - Mattias, can you please attach a valid and well-formed sample XML document that unmarshals successfully against the schemas attached ?
        Hide
        Werner Guttmann added a comment -

        Mattias, as I have got a new dependency on this issue, can you please help me out with my little request ?

        Show
        Werner Guttmann added a comment - Mattias, as I have got a new dependency on this issue, can you please help me out with my little request ?
        Hide
        Werner Guttmann added a comment -

        And that's on CASTOR-1566, just to make sure.

        Show
        Werner Guttmann added a comment - And that's on CASTOR-1566 , just to make sure.
        Hide
        Mattias Jiderhamn added a comment -

        There was no time to fix this before delivery, so we had to stick with 0.9.9.1.
        But now, I am back at the point of looking into upgrading!

        I will attach a full blown schema including valid XML.
        It is based on a standard use by Swedish authorities. The Danish authorities use a similar schema based on an older UBL (core component) version. What I am trying to say is: This is not a limited special use case - this is standard procedure in more and more global projects.

        AFAIK the type is not actually changed from a schema perspective, rather what is a string in a base class is restricted to an enumeration of strings in a sub class.

        The problem, in this case, is that Castor generates Java classes for the enumeration types, as of CASTOR-1267.

        I'm to unexperienced with Castor internal code to have a solution (other than undoing CASTOR-1267 ...) yet. The correct way of handling this might be setting the actual JClass of the _superClass, rather than just the name. Then in FieldInfo you can check if the type of the superclass attribute is different then the type of the current class attribute.
        Although I assume the classes are not parsed in "top to bottom" order?

        Show
        Mattias Jiderhamn added a comment - There was no time to fix this before delivery, so we had to stick with 0.9.9.1. But now, I am back at the point of looking into upgrading! I will attach a full blown schema including valid XML. It is based on a standard use by Swedish authorities. The Danish authorities use a similar schema based on an older UBL (core component) version. What I am trying to say is: This is not a limited special use case - this is standard procedure in more and more global projects. AFAIK the type is not actually changed from a schema perspective, rather what is a string in a base class is restricted to an enumeration of strings in a sub class. The problem, in this case, is that Castor generates Java classes for the enumeration types, as of CASTOR-1267 . I'm to unexperienced with Castor internal code to have a solution (other than undoing CASTOR-1267 ...) yet. The correct way of handling this might be setting the actual JClass of the _superClass, rather than just the name. Then in FieldInfo you can check if the type of the superclass attribute is different then the type of the current class attribute. Although I assume the classes are not parsed in "top to bottom" order?

          People

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

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 2 hours
              2h
              Remaining:
              Remaining Estimate - 2 hours
              2h
              Logged:
              Time Spent - Not Specified
              Not Specified