JiBX
  1. JiBX
  2. JIBX-349

Incorrect JiBX binding for custom marshaller / unmarshallers

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: JiBX 1.2.1
    • Fix Version/s: JiBX 1.2.3
    • Component/s: core
    • Labels:
      None
    • Environment:
      Maven 2.x, Groovy
    • Testcase included:
      yes
    • Number of attachments :
      4

      Description

      There appears to be a class re-use issue with custom unmarshallers when the JiBX binding is being generated. I have a code base that was bound correctly in JiBX 1.1.6a but now does not work correctly. There appear to be two problems related to re-use of unmarshallers. In my case they were all with a generic MeasurableTranslator class which acts as both a marshaller and an unmarshaller.

      1) The ball-length child of the yarn-type element is not processed at all, yet its siblings (ball-weight and thickness) are processed correctly (in header.xml). As a result, if ball-length appears as a child of yarn-type, JiBX throws an exception because it does not recognize the element.
      2) The until-measures element mapping (in block-operations.xml) appears to map to the first JiBX class in the binding generated for that unmarshaller (in this case, stitch-gauge); it does not get its own mapping but it should.

      Both these issues can be resolved in the application code with a workaround. The workaround is to create subclasses of MeasurableTranslator specific to the areas causing issues (i.e. BallLengthMeasurableTranslator and UntilMeasuresMeasurableTranslator).

      1. BindingDefinition.patch
        4 kB
        Adam J Gray
      2. DirectObject.patch
        1 kB
        Adam J Gray

        Activity

        Hide
        Adam J Gray added a comment - - edited

        Patch files are coming shortly.

        Show
        Adam J Gray added a comment - - edited Patch files are coming shortly.
        Hide
        Adam J Gray added a comment -

        Patch files updated. As stated, they aren't the most architecturally sound fixes, but if it helps point someone in the right direction or provides a "good enough" fix for anyone facing this issue now, I'm happy to share.

        If someone does have a better fix for this or better ideas, toss 'em in.

        Show
        Adam J Gray added a comment - Patch files updated. As stated, they aren't the most architecturally sound fixes, but if it helps point someone in the right direction or provides a "good enough" fix for anyone facing this issue now, I'm happy to share. If someone does have a better fix for this or better ideas, toss 'em in.
        Hide
        Adam J Gray added a comment -

        FYI, there's still a bug in those patch files. I'm still working on getting a correct solution though until I hear otherwise.

        Show
        Adam J Gray added a comment - FYI, there's still a bug in those patch files. I'm still working on getting a correct solution though until I hear otherwise.
        Hide
        Adam J Gray added a comment -

        Patch files update. Still not bullet-proof, but better at least.

        Show
        Adam J Gray added a comment - Patch files update. Still not bullet-proof, but better at least.
        Hide
        Dennis Sosnoski added a comment -

        Fixed by change to DirectObject to use unique class names for generated custom marshaller/unmarshaller subclasses. Thanks for your work in helping isolate the problem, Adam - it was actually due to DirectObject reusing the subclass name, but you were on the right track in finding it was a marshaller/unmarshaller class name issue. Thanks, too, for supplying a test case that allowed me to see the problem in action.

        Show
        Dennis Sosnoski added a comment - Fixed by change to DirectObject to use unique class names for generated custom marshaller/unmarshaller subclasses. Thanks for your work in helping isolate the problem, Adam - it was actually due to DirectObject reusing the subclass name, but you were on the right track in finding it was a marshaller/unmarshaller class name issue. Thanks, too, for supplying a test case that allowed me to see the problem in action.

          People

          • Assignee:
            Dennis Sosnoski
            Reporter:
            Jonathan Whitall
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: