JiBX
  1. JiBX
  2. JIBX-337

Make Jibx unmarshallers laxer when dealing with unexpected tags in an incoming XML message

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None
    • Number of attachments :
      0

      Description

      According to the binding tutorial (http://jibx.sourceforge.net/binding/tutorial/binding-structures.html), if there are some tags in the XML message we want to ignore, they still have to be specified in the binding configuration (e.g. of the <instructions> tag in the <customer> tag at the end of the given tutorial webpage), whereas it may not be a mandatory tag in the XML (for example, according to the cardinality in a schema definition).

      This is a problem for the following use case :

      • an external provider of an XML message has added a tag (optional or not)
      • new binding files and/or new code managing this new tag have not been redeployed
      • but it should not be a problem because you don't need in the Java code the data inside this XML tag

      So, the problem is that if the binding configuration file has not been modified to manage an useless XML tag, the binding conversion simply crashes when encounter such an unexpected XML tag.

      I don't know which would be the effort to do some code changes to make the binding a bit laxer, from this point of view, but we think it could be a great improvement for all the Jibx users. Maybe this lax behaviour can also be set up for a complete binding configuration or just for a tag.
      I could obviously be involved in realizing the changes, any information about where are the "key" parts of the code impacted is welcome.

      Obviously, this kind of behaviour is only useful for unmarhsalling purpose since for marshalling Jibx would not know from any way how to add an XML tag if it is not specified in the binding.xml configuration file.
      So such a feature still would be very interesting for software components whose incoming messages are different from the outcoming ones, which is the case of significant amount of current software components.

        Activity

        Hide
        Dennis Sosnoski added a comment -

        You can use the flexible="true" option to allow unknown elements, though this does have some limitations (http://jibx.sourceforge.net/binding/binding-attributes.html#structure).

        For 2.0 I'm planning to implement what I'd call element-driven unmarshalling, basically as the equivalent of flexible="true" on every nesting component of the binding.

        Show
        Dennis Sosnoski added a comment - You can use the flexible="true" option to allow unknown elements, though this does have some limitations ( http://jibx.sourceforge.net/binding/binding-attributes.html#structure ). For 2.0 I'm planning to implement what I'd call element-driven unmarshalling, basically as the equivalent of flexible="true" on every nesting component of the binding.
        Hide
        Dennis Sosnoski added a comment -

        Duplicate of JIBX-18

        Show
        Dennis Sosnoski added a comment - Duplicate of JIBX-18

          People

          • Assignee:
            Dennis Sosnoski
            Reporter:
            Guillaume CERNIER
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: