castor

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

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

Dates

  • Created:
    Updated:

Time Tracking

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