JiBX
  1. JiBX
  2. JIBX-296

org.jibx.runtime.JiBXException: Conflicting mappings for class ... in binding a trivial recursive mapping

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JiBX 1.2.1
    • Fix Version/s: JiBX 1.2.2
    • Component/s: core
    • Labels:
      None
    • Environment:
      Windows Vista (but I think this is not relevant)
    • Number of attachments :
      2

      Description

      The CodeGen generates the valid-binding.xml file for the very simple test schema Family.xsd, but the binding compiler gives up giving this error:

      Error running binding compiler

          • Error during code generation for file 'valid-binding.xml' - please enter a bug report for this error in Jira if the problem is not listed as fixed on the online status page ***

      org.jibx.runtime.JiBXException: Conflicting mappings for class PersonType
      at org.jibx.binding.def.DefinitionContext.addMapping(DefinitionContext.java:214)
      at org.jibx.binding.def.BindingBuilder.unmarshalMapping(BindingBuilder.java:1814)
      at org.jibx.binding.def.BindingBuilder.unmarshalMappings(BindingBuilder.java:1128)
      at org.jibx.binding.def.BindingBuilder.unmarshalBindingDefinition(BindingBuilder.java:2103)
      at org.jibx.binding.Utility.loadBinding(Utility.java:314)
      at org.jibx.binding.Utility.loadFileBinding(Utility.java:431)
      at org.jibx.binding.Compile.compile(Compile.java:212)
      at org.jibx.binding.ant.CompileTask.execute(CompileTask.java:248)
      ... omissis ...

      1. Family.xsd
        0.8 kB
        Luca Buraggi
      2. valid-binding.xml
        0.6 kB
        Luca Buraggi

        Activity

        Hide
        Dennis Sosnoski added a comment -

        The problem here lies in the generated code going into the default package, so that the type name (PersonType) is the same as the class name (PersonType). The generated binding uses the type name for an abstract mapping, and uses the class name for a concrete mapping - hence the conflict.

        I've changed the code to use a default package name "dflt" for no-namespace schema components, which avoids this issue. A better solution will have to wait for 2.0.

        Show
        Dennis Sosnoski added a comment - The problem here lies in the generated code going into the default package, so that the type name (PersonType) is the same as the class name (PersonType). The generated binding uses the type name for an abstract mapping, and uses the class name for a concrete mapping - hence the conflict. I've changed the code to use a default package name "dflt" for no-namespace schema components, which avoids this issue. A better solution will have to wait for 2.0.

          People

          • Assignee:
            Dennis Sosnoski
            Reporter:
            Luca Buraggi
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: