castor

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:

Time Tracking

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