castor
  1. castor
  2. CASTOR-1978

Unmarshalling fails if substitution groups used in schema.

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1.1
    • Fix Version/s: None
    • Component/s: XML code generator
    • Labels:
      None
    • Environment:
      Windows XP Professional, Java 1.4.2_12-b03
    • Number of attachments :
      1

      Description

      We are using castor-1.1.1, and java build 1.4.2_12-b03.

      We have attached a schema and instance document that uses
      substitution groups.

      We successfully generate Castor classes with the following command:

      java -cp xerces-J_1.4.0.jar;commons-logging-1.1.jar;castor-1.1.1-xml.jar;cast or -1.1.1-codegen.jar org.exolab.castor.builder.SourceGeneratorMain -i EasyPo.xsd -package po

      However, when we try to unmarshall the attached xml we get Castor Exceptions:

      unable to find FieldDescriptor for 'book' in ClassDescriptor of invoice-header

      {F ile: [not available]; line: 29; column: 20}

      For some reason, Castor doesn't like 'book' - however, if book is
      replaced by product - everything works fine. However, that is
      invalid xml (product is abstract). In fact, ship-comment has the
      same problem. It would appear that the substitution groups are not
      being Castorized properly, or perhaps we're doing something wrong?

      PurchaseOrder vcList = new PurchaseOrder();

      try

      { Unmarshaller unmar = new Unmarshaller(PurchaseOrder.class); vcList = (PurchaseOrder) unmar.unmarshal( new InputSource( new StringReader( xmlBuf.toString() ) ) ); }

      catch (Exception e)

      { ... }

      Compile: javac -classpath .\castor-1.1.1-xml.jar SendXMLFile.java
      Run: java -classpath .\castor-1.1.1-xml.jar SendXMLFile

      We have set the automaticConflictResolution=true and left
      automaticConflictResolutionTypeSuffix=By.

      We still have the same problems.

        Activity

        Hide
        Werner Guttmann added a comment -

        I think I have identified two areas within Castor that need a cleanup. I think I should be able to come up with a small work-around by tomorrow, hoping that this is actually possible for you, and have a final solution ready within a few days. The problems are related to namespace use (oddly enough, as the test case I have been using during development are fairly complicated), and the sequence order validation in the context of substitution groups.

        Show
        Werner Guttmann added a comment - I think I have identified two areas within Castor that need a cleanup. I think I should be able to come up with a small work-around by tomorrow, hoping that this is actually possible for you, and have a final solution ready within a few days. The problems are related to namespace use (oddly enough, as the test case I have been using during development are fairly complicated), and the sequence order validation in the context of substitution groups.
        Hide
        Werner Guttmann added a comment -

        Well, here's the work around(s):

        • Can you change the namespace declaration

        xmlns:po="http://xmlbeans.apache.org/samples/substitutiongroup/easypo"

        to

        xmlns="http://xmlbeans.apache.org/samples/substitutiongroup/easypo"

        for the time being, and enable lenient sequence order check for the time being (in a custom castor.properties file), whilst we look at the underlying problems ?

        And I just noticed that substitution groups with simple types (e.g. xs:string) are still not supported currently (actually never have been).

        Show
        Werner Guttmann added a comment - Well, here's the work around(s): Can you change the namespace declaration xmlns:po="http://xmlbeans.apache.org/samples/substitutiongroup/easypo" to xmlns="http://xmlbeans.apache.org/samples/substitutiongroup/easypo" for the time being, and enable lenient sequence order check for the time being (in a custom castor.properties file), whilst we look at the underlying problems ? And I just noticed that substitution groups with simple types (e.g. xs:string) are still not supported currently (actually never have been).
        Hide
        Werner Guttmann added a comment -

        I have been able to attach patches to both sub-tasks. With these patches integrated, I am now able to deal with your sample XML schema and XML document instance provided that I exclude the 'comment' subsitution groups from scope.

        Show
        Werner Guttmann added a comment - I have been able to attach patches to both sub-tasks. With these patches integrated, I am now able to deal with your sample XML schema and XML document instance provided that I exclude the 'comment' subsitution groups from scope.
        Hide
        Werner Guttmann added a comment -

        Ted, just committed patches for the two sub-tasks I created a few hours ago. Which removes some of the problems, but not all of them. Right now, there's no easy way to provide you with a solution/work-around for the <comment> substitutes. The problem is that Castor - by definition - does not create classes for simple types and global elements based upon a simple type. Changing this global strategy will not be easy .. and will require us to think about a few things before going about a potential change.

        Having said that, I'd still appreciate any feedback re: my comments and the patches just submitted.

        Show
        Werner Guttmann added a comment - Ted, just committed patches for the two sub-tasks I created a few hours ago. Which removes some of the problems, but not all of them. Right now, there's no easy way to provide you with a solution/work-around for the <comment> substitutes. The problem is that Castor - by definition - does not create classes for simple types and global elements based upon a simple type. Changing this global strategy will not be easy .. and will require us to think about a few things before going about a potential change. Having said that, I'd still appreciate any feedback re: my comments and the patches just submitted.
        Hide
        Werner Guttmann added a comment -

        Ted, when I refer to the term 'simple type', it actually does not make a difference whether I am talking about a global element definition such as

        <element name="comment" type="xs:string" abstract="true" />

        or

        <element name="comment" type="xs:simpleString" abstract="true" />

        where 'simpleString' is a simple type definition (that for example restricts xs:string). In both cases Castor will not create a separate class for the global element 'comment'. As such, Castor's current behaviour re: class generation for simple types sort of contradicts the requirements to actually create a class if a substitutionGroup attribute is involved.

        It looks like we will have to change Castor in this case, but having looked at the sources, I tend to believe that this is not going to be an easy change.

        Show
        Werner Guttmann added a comment - Ted, when I refer to the term 'simple type', it actually does not make a difference whether I am talking about a global element definition such as <element name="comment" type="xs:string" abstract="true" /> or <element name="comment" type="xs:simpleString" abstract="true" /> where 'simpleString' is a simple type definition (that for example restricts xs:string). In both cases Castor will not create a separate class for the global element 'comment'. As such, Castor's current behaviour re: class generation for simple types sort of contradicts the requirements to actually create a class if a substitutionGroup attribute is involved. It looks like we will have to change Castor in this case, but having looked at the sources, I tend to believe that this is not going to be an easy change.

          People

          • Assignee:
            Werner Guttmann
            Reporter:
            Ted Troccola
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

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