castor

Importing from same namespace multiple times where one import actually includes the other fails

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0
  • Fix Version/s: 1.1.1
  • Component/s: XML
  • Labels:
    None
  • Testcase included:
    yes
  • Number of attachments :
    2

Description

If a schema imports multiple schemas from the same namespace:

<xs:import namespace="urn:acme.com:test:schemas" schemaLocation="PersonsA.xsd"/>
<xs:import namespace="urn:acme.com:test:schemas" schemaLocation="PersonsB.xsd"/>

Then the results are merged per code in the ImportUnmarshaller:

//-- check schema location, if different, allow merge
if (hasLocation) { String tmpLocation = importedSchema.getSchemaLocation(); alreadyLoaded = schemaLocation.equals(tmpLocation); }

However if in this case PersonsB imports PersonsA. What happens is that you get an error when processing the type info from PersonsA a second time saying the info is already there.

The fix is to do the following:
//-- check schema location, if different, allow merge
if (hasLocation) { String tmpLocation = importedSchema.getSchemaLocation(); alreadyLoaded = schemaLocation.equals(tmpLocation) || importedSchema.includeProcessed(schemaLocation); //-- keep track of the original schemaLocation as an include if(! alreadyLoaded) importedSchema.addInclude(tmpLocation); }

Note this is related to bug CASTOR-711, which actually appears fixed, but not for this case..

Activity

Hide
Werner Guttmann added a comment -

Any chances for supplying me with a patch in form of a unified diff ?

Show
Werner Guttmann added a comment - Any chances for supplying me with a patch in form of a unified diff ?
Hide
Werner Guttmann added a comment -

It looks like your patch fixes one problem, but as far as I can tell, there's now two descriptor classes that do not compile any more. In addition, can you please attach a proper unified diff, as above code fragment (due to Jira formatting) is quite ambiguous ....

Show
Werner Guttmann added a comment - It looks like your patch fixes one problem, but as far as I can tell, there's now two descriptor classes that do not compile any more. In addition, can you please attach a proper unified diff, as above code fragment (due to Jira formatting) is quite ambiguous ....
Hide
Werner Guttmann added a comment -

Hmm, just looking at the PersonSearch.xsd XMl schema. Somehow this looks a bit odd to me. Eclipse's XML editor seems to be reporting that it cannot find the element reference to <eprson:Persons>. Which actually might be correct, as you are importing two XML schemas using the same namespace declaration.

Wouldn't it be sufficient to import just PersonB, as PersonB.xsd includes PersonA.xsd ?

Show
Werner Guttmann added a comment - Hmm, just looking at the PersonSearch.xsd XMl schema. Somehow this looks a bit odd to me. Eclipse's XML editor seems to be reporting that it cannot find the element reference to <eprson:Persons>. Which actually might be correct, as you are importing two XML schemas using the same namespace declaration. Wouldn't it be sufficient to import just PersonB, as PersonB.xsd includes PersonA.xsd ?
Hide
Werner Guttmann added a comment -

Adding the following property definition to a custom builder property file

  1. Specifies an XML namespace to Java package mapping.
  2. There is no default mapping.
    #
    org.exolab.castor.builder.nspackages=\
    urn:active-endpoints.com:test:schemas=xml.c1935.generated

resolved the compilation problems.

Show
Werner Guttmann added a comment - Adding the following property definition to a custom builder property file
  1. Specifies an XML namespace to Java package mapping.
  2. There is no default mapping. # org.exolab.castor.builder.nspackages=\ urn:active-endpoints.com:test:schemas=xml.c1935.generated
resolved the compilation problems.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: