jaxb
  1. jaxb
  2. JAXB-914

Unmarshalled hexBinary is null when XML contains starting or trailing whitespace chars

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.5, 2.2.7
    • Fix Version/s: None
    • Component/s: runtime
    • Labels:
      None

      Description

      While unmarshalling, when the source XML contains something like:

          ...
          <someData>
      f33a8d1800156efa876656790102508a1f080508150835081508d508
          </someData>
          ...
      

      where someData is of type hexBinary, parsing will work, unmarshalling will work, even XSD Schema validation will work. But the corresponding property in the created bean instance will have a null value.

      If I replace that with:

          ...
          <someData>f33a8d1800156efa876656790102508a1f080508150835081508d508</someData>
          ...
      

      everything works fine.

      The w3c spec seems pretty clear about the fact that hexBinary elements are not allowed to contain whitespaces: http://www.w3.org/TR/xmlschema11-2/#hexBinary

      The set recognized by hexBinary is the same as that recognized by the regular expression '([0-9a-fA-F]{2})*'.

      So with this in mind, I tend to put the blame on the jaxp schema validation for allowing the content with beginning and trailing whitespace and newline characters in the first place. Nevertheless, the result is an inconsistency between jaxp and jaxb which puts the framework user between two chairs: On one hand, none of the validation checks fail, which lets us think that the input xml is actually valid. On the other hand, when we retrieve the value from the unmarshalled bean, we get a null value on a field that passes XSD validation and, in our XSD, is not even allowed to contain null. There doesn't seem to be any 'clean' way out if this as it stands now...

      In my opinion, the validation should either fail, or the bean should contain the expected value. The current behavior is worst case.

      Even though jaxp schema validation should probably be blamed for this, I think you should at least make the behavior consistent by trimming the string before hex-encoding it (you chose to use jaxp for validation after all ).

      Here's a quick patch for javax.xml.bind.annotation.adapters.HexBinaryAdapter that should do the trick:

          public byte[] unmarshal(String s) {
              if(s==null)     return null;
      --      return DatatypeConverter.parseHexBinary(s);
      ++      return DatatypeConverter.parseHexBinary(s.trim());
          }
      

      Even though this behavior is less restrictive than the XSD specification, I don't think it's any more harming than the current behavior. Moreover, if jaxp ever "fixes" the problem, jaxb would either fail validation (if validation is enabled), or just return a plausible result (if validation is disabled), which also seems like a good behavior.

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Martin Grebac
            Reporter:
            mike_meessen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: