castor
  1. castor
  2. CASTOR-1935

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 Specifies an XML namespace to Java package mapping. There is no default mapping. # org.exolab.castor.builder.nspackages=\ urn:active-endpoints.com:test:schemas=xml.c1935.generated resolved the compilation problems.

          People

          • Assignee:
            Werner Guttmann
            Reporter:
            Chris Keller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: