You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@johnzon.apache.org by "Steven Walters (JIRA)" <ji...@apache.org> on 2017/12/29 15:45:00 UTC

[jira] [Comment Edited] (JOHNZON-151) Serializing nulls within a list, within a type or map produces unexpected results

    [ https://issues.apache.org/jira/browse/JOHNZON-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306349#comment-16306349 ] 

Steven Walters edited comment on JOHNZON-151 at 12/29/17 3:44 PM:
------------------------------------------------------------------

I could open a PR with a possible path to resolution, but should probably have the general direction settled first.

for the NPE issue starting in 1.1.5, this seems easy enough with adding a null check, so from
{{if (objectConverterToUse == null)}} to {{if (objectConverterToUse == null && o != null)}}

For the null inclusion/skipping. this seems like it could be in writePrimitives such as 
{code}
if (value == null) {
    if (!config.isSkipNull()) {
        generator.writeNull();
    }
    return true;
}
{code}
so the config would drive the inclusion of nulls as appropriate.

if this sounds adequate, I can open a PR later.


was (Author: steven.walters):
I could open a PR with a possible path to resolution, but should probably have the general direction settled first.

for the NPE issue starting in 1.1.5, this seems easy enough with adding a null check, so from {{if (objectConverterToUse == null)}} to {{if (objectConverterToUse == null && o != null)}}

For the null inclusion/skipping. this seems like it could be in writePrimitives such as 
{code}
if (value == null) {
    if (!config.isSkipNull()) {
        generator.writeNull();
    }
    return true;
}
{code}
so the config would drive the inclusion of nulls as appropriate.

if this sounds adequate, I can open a PR later.

> Serializing nulls within a list, within a type or map produces unexpected results
> ---------------------------------------------------------------------------------
>
>                 Key: JOHNZON-151
>                 URL: https://issues.apache.org/jira/browse/JOHNZON-151
>             Project: Johnzon
>          Issue Type: Bug
>          Components: Mapper
>    Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5
>            Reporter: Steven Walters
>         Attachments: johnzon-mapper-nulls-in-collection.zip
>
>
> When a Collection (such as a List) contains a null entry and is serialized through a parent map or defined type, the serialization produces unexpected results.
> With 1.1.0 through 1.1.4, the nulls are silently ignored.
> With 1.1.5, a NullPointerException occurs instead.
> I did *not* check 1.0.0
> Local analysis indicates that in 1.1.5, code block
> {code:title=MappingGeneratorImpl.java}
> private void writeValue(final Class<?> type, ...
> ...
> if (objectConverterToUse == null) {
>     objectConverterToUse = config.findObjectConverterWriter(o.getClass());
> }
> {code}
> is the culprit by trying to invoke getClass() on a null object.
> Nulls are ignored in 1.1.4 and prior due to code blocks
> {code:title=MappingGeneratorImpl.java}
> private void writeItem(final Object o, final Collection<String> ignoredProperties, JsonPointerTracker jsonPointer) {
>     if (!writePrimitives(o)) {
>         if (Collection.class.isInstance(o)) {
> {code}
> {code:title=MappingGeneratorImpl.java}
> private boolean writePrimitives(final Object value) {
>     boolean handled = false;
>     if (value == null) {
>         return true; // fake a write
>     }
> {code}
> That is, the writeItem invokes writePrimitives and writePrimitives says it handled the null, when it in fact did nothing.
> Currently serializing null within a list only produces correct results when the list is the root object of serialization.
> Test cases attached; run mvn test to see include tests against 1.1.5
> I've had to include our own altered copy of MappingGeneratorImpl to the classpath (at a higher priority) to workaround the issue indicated here in our project.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)