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

Difference in the handling of ObjectId-property in JsonIdentityInfo depending on the deserialization route #3838

Closed
k163377 opened this issue Mar 22, 2023 · 5 comments · Fixed by #3868
Labels
2.16 Issues planned for 2.16
Milestone

Comments

@k163377
Copy link
Contributor

k163377 commented Mar 22, 2023

Describe the bug
This is the problem reported in FasterXML/jackson-module-kotlin#378 .

Setter-based deserialization does not generate an error if the id-property is not present on the JSON.
On the other hand, instantiator-based deserialization throws a MismatchedInputException if the id-property is not present in the JSON.

Version information
It has been present since at least 2.9.9 and is reproduced in 2.15.0-rc1.

To Reproduce

import com.fasterxml.jackson.annotation.JsonCreator;
import com.fasterxml.jackson.annotation.JsonIdentityInfo;
import com.fasterxml.jackson.annotation.JsonProperty;
import com.fasterxml.jackson.annotation.ObjectIdGenerators;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.junit.jupiter.api.Test;

public class ObjectId {
    @JsonIdentityInfo(property = "id", generator = ObjectIdGenerators.PropertyGenerator.class)
    static class SetterBased {
        private String id;

        public String getId() {
            return id;
        }

        public void setId(String id) {
            this.id = id;
        }
    }

    @JsonIdentityInfo(property = "id", generator = ObjectIdGenerators.PropertyGenerator.class)
    static class CreatorBased {
        private final String id;

        @JsonCreator
        CreatorBased(@JsonProperty(value = "id") String id) {
            this.id = id;
        }

        public String getId() {
            return id;
        }
    }

    @Test
    void test() throws JsonProcessingException {
        ObjectMapper mapper = new ObjectMapper();

        // -> no error
        SetterBased t1 = mapper.readValue("{}", SetterBased.class);
        System.out.println(t1.id); // -> null

        // -> MismatchedInputException thrown
        CreatorBased t2 = mapper.readValue("{}", CreatorBased.class);
    }
}

Expected behavior
It would be correct to be one of the following summarized below.
FasterXML/jackson-module-kotlin#378 (comment)

Additional context
n/a

@k163377 k163377 added the to-evaluate Issue that has been received but not yet evaluated label Mar 22, 2023
@cowtowncoder cowtowncoder changed the title Difference in the handling of id-property in JsonIdentityInfo depending on the deserialization route. Difference in the handling of ObjectId-property in JsonIdentityInfo depending on the deserialization route. Mar 22, 2023
@JooHyukKim
Copy link
Member

JooHyukKim commented Apr 5, 2023

Anyone working on this issue?
This one seems interesting. Can I try to resolve this issue?

@cowtowncoder
Copy link
Member

@JooHyukKim No one working AFAIK so feel free to!

@JooHyukKim
Copy link
Member

JooHyukKim commented Apr 7, 2023

I read about the issue (FasterXML/jackson-module-kotlin#378).

The desired outcome is to throw a MismatchedInputException even for the "SetterBased" case. Can you confirm this, @cowtowncoder? Thank you! 👍

PS: I made a PR in #3868.

@cowtowncoder
Copy link
Member

@JooHyukKim I think so, although did not dig deep enough (too many things to juggle at this point, alas).

@cowtowncoder cowtowncoder changed the title Difference in the handling of ObjectId-property in JsonIdentityInfo depending on the deserialization route. Difference in the handling of ObjectId-property in JsonIdentityInfo depending on the deserialization route Jun 13, 2023
@cowtowncoder cowtowncoder added 2.16 Issues planned for 2.16 and removed to-evaluate Issue that has been received but not yet evaluated labels Jun 13, 2023
@cowtowncoder cowtowncoder added this to the 2.16.0 milestone Jun 13, 2023
cowtowncoder added a commit that referenced this issue Jun 13, 2023
@cowtowncoder
Copy link
Member

Thank you @JooHyukKim, as usual! Fix will be in 2.16.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.16 Issues planned for 2.16
Projects
None yet
3 participants