Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Null String field serialization through ToXmlGenerator causes NullPointerException #413

Closed
jimnz111 opened this issue Jun 20, 2020 · 3 comments
Milestone

Comments

@jimnz111
Copy link

Using jackson-data-format-xml Version 2.10.2

I am using a custom serializer for an pojo to allow conversion to json or xml. It will pass null values for String and Number fields as opposed to "" and 0 into the serializer.

For json everything works as intended and the json would look like this example

{
   field1: null,
   field2: "value"
}

The output must also be available in XML, and that uses ToXmlGenerator for serializing the data. Where a String field is null, it will fail in woodstox BaseStreamWriter with a NullPointerException, as it assumes the String passed is never a null.

A snippet of the stacktrace shows the path it went through

java.lang.NullPointerException: null
	at com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:458)
	at com.fasterxml.jackson.dataformat.xml.ser.ToXmlGenerator.writeString(ToXmlGenerator.java:622)
	at com.fasterxml.jackson.dataformat.xml.ser.ToXmlGenerator.writeStringField(ToXmlGenerator.java:460)
	at com.fis.core.json.JsonGeneratorPojoFieldVisitor.lambda$2(JsonGeneratorPojoFieldVisitor.java:170)

In ToXmlGenerator the writeString(String text) method does not check for a null String. Looking at the other methods eg writeNumber(BigInteger value) there is this code to check for a null

if (value == null) {
    writeNull();
    return;
}

I couldn't find any reason that the writeString(String) shouldn't also check for a null value. I checked in version 3.0 and there is no changes for it. There may well be a valid explanation of why it shouldn't check for a null. For me I found a workaround for this in that I check in my serializer that if the string is null to instead call writeNullField(String fieldName). Some developers may not have this capability, and if it can instead call the writeNull() it would remove the potential for NPE.

Can the check for null String be added to the method in ToXmlGenerator.writeString(String)?

@cowtowncoder
Copy link
Member

Short answer is that one should not call JsonGenerator.writeString() will null argument: this is not supported use case; writeNull() should be called instead.
Same is actually true for writeNumber() and other methods, but there may have been some reason to allow nulls writeObject().

So I don't think JsonGenerator should add special handling that all implementations (there are about dozen different backends) would need to support.

@jimnz111
Copy link
Author

jimnz111 commented Jun 22, 2020

The behaviour differs between ToXmlGenerator and UTF8JsonGenerator in that UTF8JsonGenerator.writeString(String) is checking for null in UTF8JsonGenerator. We are using Spring Boot and it handles the implementations called under the covers, and having it work the same whether xml or json output would be better.

I spent quite a number of hours thinking the issue was a jaxb annotation one because of the json serializer working. If the change can be made in ToXmlGenerator, this would ensure that regardless of content type to be output, they behave the same.

Heres a pic of UTF8JsonGenerator.writeString(String) showing the check

image

@cowtowncoder
Copy link
Member

Ah. Ok, if it exists in general JSON generator, I can see why it should also exist in ToXmlGenerator.
I would probably recommend fix for 2.11 branch, although seems safe enough for 2.10 if necessary (2.11.1 likely to be released before 2.10.5, for what that's worth).

@cowtowncoder cowtowncoder added this to the 2.10.5 milestone Jun 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants