FasterXML
Trouble dealing with JacksonXMLText if properties are present or if element is in a collection
Given the xml of:
<project><text> </text></project>
and the Text.java of:
public class Text {
private String content;
public Text() {
}
@JacksonXmlText
public String getContent() {
return content;
}
public void setContent(String content) {
this.content = content;
}
}
The setContent method will be called with the whitespace contained in <text>. However, if I add (with Text.java having "id" as an attribute):
<project><text id="test"> </text></project>
The setContent call will be skipped when it only contains whitespace. However, non-whitespace only text:
<project><text id="test">hello world!</text></project>
would have setContent with "hello world!" passed in
Additionally, if I were to use the xml:
<project><text> </text><text>hello world!</text></project>
...and have Project contain a List of Texts (whether wrapped or unwrapped), it will result in the same failure. The second Text object will have the contents of "hello world!", but the first will contain null rather than it's whitespace.
I'm struggling with how to work around this as the items I'm dealing with really represent text in a document and sometimes I will have empty strings (which have meaning, but I could deal with those being null) or whitespace (spaces) which have meaning.
Just to make sure: is this with 2.12.1? (just asking since 2.12 contained many fixes over 2.11 and earlier versions).
White-space handling is rather tricky unfortunately, and it usually needs to be trimmed (to avoid indentation breaking data-oriented use cases). But I think the case of attribute and XmlText should be supportable at least. The other case is bit different and needs to be handled separately, as Collection entries are another challenging area. So I consider this issue to be wrt element-with-attribute and all-whitespace content.
I'll have to point out that although the specific case of white-space-only element content might be something that can be made to work, in general it is not possible to fully support mixed-content types. Since for most usage white-space segments between start/end elements are to be ignored (typically indentation for pretty-printing), they are usually to be ignored.
But with that, cases presented here sound reasonable, to expect there was no difference. I may split this into two issues if it looks like handling between attribute-and-ws vs list of strings differs.