JiBX
  1. JiBX
  2. JIBX-306

Issue binding multiple elements in collection after upgrading from 1.1.5 -> 1.2.1

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: JiBX 1.2.1
    • Fix Version/s: None
    • Component/s: BindGen
    • Labels:
      None
    • Environment:
      Windows XP, OSX ,JDK 1.5
    • Testcase included:
      yes
    • Number of attachments :
      3

      Description

      NOTE: attached is a runnable sample: run "mvn test" to see it running successfully, then changed the jibx.version property in pom.xml and re-run to see it failing with a similar error to below.

      We marshall the following type of XML where Option, Color and UsedFeature all extend a Feature class:

      <features>
      <option>
      <feature ..
      </option>
      <option>
      <feature ..
      </option
      <color>
      <feature ..
      </color>
      <color>
      <feature ..
      </color>
      <usedFeature>
      <feature...
      </usedFeature>
      </features>

      The following bindings XML is used to define a Set of Features belonging to another object. Any one of option, color or usedFeature can occur any number of times:

      <mapping ns="http://www.edmunds.com/esbservices/schemas" class="com.edmunds.vehicle.coherence.ModelYearImpl"
      name="modelYear" post-set="postset">
      ...
      <structure name="features" field="features" usage="optional" map-as="features-set"/>
      ....
      </mapping>

      <mapping abstract="true" type-name="features-set" class="java.util.Set" create-type="java.util.HashSet">
      <collection ordered="false">
      <structure name="option" type="com.edmunds.vehicle.coherence.OptionImpl"
      marshaller="com.edmunds.vehicle.util.jibx.FeatureIdRefMapper"
      unmarshaller="com.edmunds.vehicle.util.jibx.FeatureIdRefMapper"/>
      <structure name="color" type="com.edmunds.vehicle.coherence.ColorImpl"
      marshaller="com.edmunds.vehicle.util.jibx.FeatureIdRefMapper"
      unmarshaller="com.edmunds.vehicle.util.jibx.FeatureIdRefMapper"/>
      <structure name="usedFeature" type="com.edmunds.vehicle.coherence.UsedFeatureImpl"
      marshaller="com.edmunds.vehicle.util.jibx.FeatureIdRefMapper"
      unmarshaller="com.edmunds.vehicle.util.jibx.FeatureIdRefMapper"/>
      </collection>
      </mapping>

      This all worked fine with Jibx 1.1.5, but with 1.2.1 I get an error informing me that it was expecting all of the elements to be of the same type (option OR color OR usedFeature), i.e.

      java.lang.RuntimeException: org.jibx.runtime.JiBXException: Expected "

      {http://www.edmunds.com/esbservices/schemas}

      features" end tag, found "

      {http://www.edmunds.com/esbservices/schemas}

      color" start tag (line 1, col 75244)
      at com.edmunds.vehicle.end2end.VehicleEndToEndTest.saveMakeTree(VehicleEndToEndTest.java:135)
      Caused by: org.jibx.runtime.JiBXException: Expected "

      {http://www.edmunds.com/esbservices/schemas}

      features" end tag, found "

      {http://www.edmunds.com/esbservices/schemas}

      color" start tag (line 1, col 75244)
      at org.jibx.runtime.impl.UnmarshallingContext.parsePastCurrentEndTag(UnmarshallingContext.java:736)

        Activity

        Hide
        Aidan OLoan added a comment -

        We were able to fix this issue by adjusting how the 'suffix' variable was created in the DirectObject.createSubclass() method. See attached files.

        Show
        Aidan OLoan added a comment - We were able to fix this issue by adjusting how the 'suffix' variable was created in the DirectObject.createSubclass() method. See attached files.
        Hide
        Aidan OLoan added a comment -

        Proposed fixed files.

        Show
        Aidan OLoan added a comment - Proposed fixed files.
        Aidan OLoan made changes -
        Field Original Value New Value
        Attachment BindingDefinition.java [ 43626 ]
        Attachment DirectObject.java [ 43627 ]
        Dennis Sosnoski made changes -
        Assignee Dennis Sosnoski [ dsosnoski ]
        Hide
        Dennis Sosnoski added a comment -

        I'm not able to work with the supplied maven build - can you please provide the problem demonstration with an Ant build instead? I'd like to get the fix in place, but there've been too many changes from the version you used to generate your diff and I'm not willing to try making the changes without a test I can use to recreate the problem and verify a solution.

        Show
        Dennis Sosnoski added a comment - I'm not able to work with the supplied maven build - can you please provide the problem demonstration with an Ant build instead? I'd like to get the fix in place, but there've been too many changes from the version you used to generate your diff and I'm not willing to try making the changes without a test I can use to recreate the problem and verify a solution.

          People

          • Assignee:
            Dennis Sosnoski
            Reporter:
            Aidan OLoan
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: